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

Александр Фролов
На сайте с 27.12.2007
Offline
155
9141

В продолжение темы: Нужно оценить затраты на создание и сопровождение HA-кластера

Кратко о поставленной задаче: нужно создать отказоустойчивый кластер для высоконагруженного интернет-магазина (примерно 100К запросов к базе данных в минуту). Сейчас проект работает на одном сервере FreeBSD (48 Гбайт памяти, зеракло на 15К дисках SAS, контроллер LSI с батарейкой). Софт: Apache, Nginx, memcached, MySQL, MongoDB и Sphinx (последние два добавились недавно).

В целом текущее быстродействие удовлетворяет, однако нужна отказоустойчивость.

Сначала рассматривались два варианта: ISPManager Cluster и кластер на RedHat Enterprise Linux, но оба варианта обладают существенными недостатками.

ISPManager Cluster

По умолчанию используется NFS, а также репликация MySQL в режиме Master-Slave.

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

После этого я перешел к рассмотрению второго варианта:

Кластер на RedHat Enterprise Linux

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

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

Ну и основные опасения насчет кластера MySQL, так как нет своего опыта его сопровождения.

После общения с поставщиком серверов мне подсказали третий вариант:

Кластер на IBM System x3850 X5

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

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

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

Попутно хочу поизучать установку кластера Linux. Ищу для этого какие-нибудь недорогие неттопы, чтобы они не шумели и не занимали много места. Единственное - не знаю, что купить, чтобы CentOS или Scientific Linux встали туда без необходимости поиска и ручной установки драйверов, т.к. в линуксе я не силен...

zexis
На сайте с 09.08.2005
Offline
388
#1

От какого рода отказов вы хотите защититься?

Если от отказов жестких дисков, то от них надежно защитит RAID с качественным контроллером.

От отказов блоков питания можно защитится взяв корпус с 2-мя блоками питания с возможностью их горячей замены без выключения сервера. Цена такого корпуса 1U Supermicro около 55 000 руб.

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

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

Проблемы с ними более вероятны чем с железом.

По статистике даже в надежных ДЦ 1-3 раза в год происходит какой то перебой, то со светом, то с каналами.

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

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

А синхронизацию базы данных между разными серверами средствами репликаций БД и средствами приложений.

Но здесь не обойтись без опытного специалиста на постоянной основе.

Александр Фролов
На сайте с 27.12.2007
Offline
155
#2
zexis:
От какого рода отказов вы хотите защититься?

По нашему опыту, чаще всего выходят из строя диски SATA, но мы теперь их не используем. Зеркало с горячим резервом на третьем диске имеется. Была проблема и с выходим из строя блока питания, правда, не на нашем, а не арендованном сервере.

Проблем с выходом из строя вентилляторов, системных плат, памяти и сетевых интерфейсов пока не было, но хотелось бы защититься и от этого.

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

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

Кроме того, интересно и масштабирование при росте нагрузки.

Александр Фролов добавил 06.09.2011 в 13:08

zexis:
Но здесь не обойтись без опытного специалиста на постоянной основе.

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

zexis
На сайте с 09.08.2005
Offline
388
#3

На какой бюджет вы рассчитываете для создания отказоустойчивого решения?

Александр Фролов
На сайте с 27.12.2007
Offline
155
#4
zexis:
На какой бюджет вы рассчитываете для создания отказоустойчивого решения?

Видимо, не очень большой, все же это оптовый интернет-магазин, а не газпром)

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

Если денег хватит на решение от IBM, то хорошо, т.к. сервер приложений и MySQL можно сделать на этом решении, а при масшатбировании разносить по хостам, например, нетранзакционные данные MongoDB. А вот если денег не хватит, надо будет изучать различные предложения на базе кластера Linux и оценивать стоимость создания и сопровождения. Чем я, собственно, сейчас и пытаюсь заниматься...

Но пока мне попадаются только компании, которые либо делают кластеры на решениях Microsoft, либо не имеют опыта в создании и обслуживании кластеров MySQL.

P
На сайте с 08.03.2007
Offline
250
#5
Александр Фролов:
Но пока мне попадаются только компании, которые либо делают кластеры на решениях Microsoft, либо не имеют опыта в создании и обслуживании кластеров MySQL.

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

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

Александр Фролов
На сайте с 27.12.2007
Offline
155
#6
Pilat:
Насчёт тестов на неттопах. Если захотите виртуализацию использовать на них, имейте ввиду - не выйдет, они не поддерживают обычно необходимые инструкции.

Вообще я думал купить парочку неттопов, воткнуть их в свич и установить на все это Scientific Linux в кластере, апач и MySQL. Другие сервисы я могу отлаживать на виртуальных машинах, работающих на WmWare, сервер уже есть. А вот балансировку нагрузки на виртуалках даже и не знаю, стоит ли смотреть.

zexis
На сайте с 09.08.2005
Offline
388
#7
Александр Фролов:
Видимо, не очень большой,

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

ИМХО распаралеливание работы на несколько серверов – задача не тривиальная, требует существенно больших затрат, а из за сложности и повышенного риска человеческого фактора, в результате надежность может оказаться даже ниже, чем работа на одном сервере.

N
На сайте с 06.05.2007
Offline
419
#8
zexis:
ИМХО распаралеливание работы на несколько серверов – задача не тривиальная, требует существенно больших затрат, а из за сложности и повышенного риска человеческого фактора, в результате надежность может оказаться даже ниже, чем работа на одном сервере.

так он не верит. опять такую же тему создал

Кнопка вызова админа ()
Александр Фролов
На сайте с 27.12.2007
Offline
155
#9
netwind:
так он не верит. опять такую же тему создал

Да я верю, что надежный сервер повысит надежность, но что будет, если мне, например, нужно забрать его на профилактику? Что если даже 10-минутный простой приведет к возникновению ущерба?

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

Кстати, MongoDb плохо реагирует на аварийное завершение.

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

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

Andreyka
На сайте с 19.02.2005
Offline
822
#10

Укажите бюджет на все это безобразие. На создание и поддержку.

Кроме того я вижу смысл сделать hp+ha кластер из четырех юнитов.

Andreyka добавил 06.09.2011 в 15:00

Александр Фролов:


Да я верю, что надежный сервер повысит надежность, но что будет, если мне, например, нужно забрать его на профилактику? Что если даже 10-минутный простой приведет к возникновению ущерба?

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

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

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

А, так нужно решение, а не реализация? У меня есть несколько наработок, свзязанных с электронной коммерцией. Если есть желание - обращайтесь.

Не стоит плодить сущности без необходимости

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий