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

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

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

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

Соответственно, видится что-то вроде пары серверов, работающих зеркалом, на каждом сервере - массив 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?

Нет конечно.

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

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


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

Нет конечно.

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

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

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

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


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

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас