Jump to content
Калькуляторы

Система Хранения Данных на чем?

Задумался я тут о внедрении СХД, а то количество серверов растет, на одном дофига свободного места, на другом - наоборот не хватает.

Денег особо не выделяется, так что аппаратные решения не рассматриваются.

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

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

Да, физически сервера все в одном месте, связаны быстрыми надежными каналами.

Требования к системе в порядке важности:

1. Отказоустойчивость.

2. ОТКАЗОУСТОЙЧИВОСТЬ!!!

3. Бесплатность (то есть GPFS не канает)

4. Скорость.

 

Пока вырисовывается только GlusterFS, но есть от него ощущение какой-то сырости пока.

Может у кого есть идеи по архитектуре, софту?

Share this post


Link to post
Share on other sites

drbd + nfs ?

А как тут быть с прозрачностью для клиентов? Если сервер, с которого подмонтирована NFS упал?

Share this post


Link to post
Share on other sites

heartbeat не дописал ;)

 

у меня так сервера хранения для esx собраны - две машины, drbd+heartbeat и nfs...

 

Ага, понял, пошел читать.

А как опыт использования? Все как задумано работает, проблем не было? Нюансы никакие не вылезают при переключении активной ноды например, таймауты там какие-нибудь?

Share this post


Link to post
Share on other sites

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

И винты вылетали, и блоки питания горели, и контроллеры рейдов накрывались.. Работаем ;)

Разве что у меня на каждой ноде 5-й рейд, но это уже дело вкуса по моему..

Share this post


Link to post
Share on other sites

Почитал немного, и есть некоторое непонимание.

Ну допустим подняли DRBD+heartbeat+NFS, раздали диск, на клиенте запустили MySQL например, с базой на NFS диске.

Накрылась одна нода, поднялась вторая, запустила NFS, а как это выглядит со стороны MySQL?

Таймаут/ошибка диска, перемонтирование раздела с другой ноды, переоткрытие файла базы, незавершенная транзакция, откат по бинлогу?

Или не все так страшно, и все гладко проходит?

Share this post


Link to post
Share on other sites

Да, физически сервера все в одном месте, связаны быстрыми надежными каналами.

 

Это плохо. Надо бы разносить сервера географически.

Share this post


Link to post
Share on other sites

Гластер вполне рабочий.

Из недостатков на текущий момент:

. в 3.3.1 сломали дисковый лимит по нодам, работает только лимит по папкам внутри тома

. синхронный

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

. если делать обычную destributed replication то не получите высокой скорости записи при высоком latency между нодами, если ваши ноды разнесены географически (в разных дц).

. нет возможности на лету увеличить "избыточность" репликации.

Share this post


Link to post
Share on other sites

При переезде (и правильно настроенных таймаутах на heartbeat) - мускул увидит какие то тормоза с диском, а потом все будет работать дальше...

Share this post


Link to post
Share on other sites

ceph, пускали и тестили на двух нодах, 3сетевых на гигабит в каждой, 16гб памяти, по десятку жестких.

получили порядка 5тыс iops на чтение и запись.

 

при нормальных дисках и хорошем контроллере можно отжать большье.

для сравнения обычный диск в среднем дает порядка 140iops

Share this post


Link to post
Share on other sites

Гластер вполне рабочий.

Из недостатков на текущий момент:

Забыли упомянуть главный - он крутится в юзерспейсе. И как результат - медленный. Очень медленный. По сравнению с ядерными решениями типа DRBD. Зато разворачивается просто, да...

Share this post


Link to post
Share on other sites

Используем сервер Synology с 8 дисками в RAID10, подключенный к XenCloudPlatform в виде iSCSI накопителя. Виртуалки работают быстро. HDTUNE под Windows внутри виртуалку говорит о производительности около 20000iops

Share this post


Link to post
Share on other sites

Надо бы разносить сервера географически.

И поиметь split-brain? :)

Ну это уж зависит от того, насколько нужна сохранность данных. :)

Share this post


Link to post
Share on other sites

Забыли упомянуть главный - он крутится в юзерспейсе. И как результат - медленный. Очень медленный. По сравнению с ядерными решениями типа DRBD. Зато разворачивается просто, да.

Все зависит от модели использования / дисков / фс на конечных нодах.

Давно не трогал DRBD, но равзе там есть возможность на лету ввести еще одну машину, и ее диск "подцепить" к уже созданному устройству ? Можно ли там раскидать "реплику" к примеру на 3 машины и чтобы все работали в режиме master?

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

Из вариантов есть еще pohmelfs с бэкендом в виде elliptics. Только модуль pohmelfs выпили из staging ядра начиная с ветки 3.4, и пока вроде не вернули :)

Share this post


Link to post
Share on other sites

Все зависит от модели использования / дисков / фс на конечных нодах.

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

 

Давно не трогал DRBD, но равзе там есть возможность на лету ввести еще одну машину, и ее диск "подцепить" к уже созданному устройству ? Можно ли там раскидать "реплику" к примеру на 3 машины и чтобы все работали в режиме master?

Нет конечно.

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

Share this post


Link to post
Share on other sites

Нет конечно.

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

Не быстрее, вариант мастер - слейв наверно даже более "нагляден" и проще контролируем с точки зерния потоков данных. Но я просто привел пример когда нужно 3-4-5-6 копий данных, и также тот случай когда объем хранилища нужно нарастить без остановки сервиса.

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.