Перейти к содержимому
Калькуляторы

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

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

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

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

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

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

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

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

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

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

4. Скорость.

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

drbd + nfs ?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

. синхронный

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Нет конечно.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Что-то тут все про DRBD, а про HAST никто и не вспомнил.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Нет конечно.

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

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

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.