Кластерные системы хранения данных

Я слышал неплохие отзывы про lustre, но сам не пользовался.

тут пора поглядеть на ынтепрайз решения пусть даже аппаратные.

или drdb попробовать. но чую он не вывезет ваши объемы.

Вам нужен infiniband

или drdb попробовать. но чую он не вывезет ваши объемы.

дрбду объемы пофиг, он же блочный. У меня, к примеру, он реплицирует крест-накрест между серверами устройства по 8 и 4Тб и даже не чешется.

Файлы должны быть доступны с двух серверов одновременно?

Да.

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

Может использовать отдельное хранилище (при необходимости - отказоустойчивое) по NFS? Будет надежнее чем такая крест-накрест репликация.

http://eval.symantec.com/mktginfo/enterprise/fact_sheets/storage_foundation_c...

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

Два сервера на обоих встречно настроенный глустер, у нас слоупочный дебьян , там так не получится )

спрошу конкретнее: gluster peer status; gluster vol status all; gluster vol profile VOLNAME start; gluster vol profile VOLNAME info; gluster vol profile VOLNAME stop ifconfig

Ну можно сделать два сервера-хранилища с DRBD + Pacemaker для репликации и отказоустойчивости. Поверх DRBD натянуть какую-нибудь ФС и экспортировать ее по NFS. Потом этот нфс монтировать уже на своих серверах.

Вот, например, хауту https://www.suse.com/documentation/sle_ha/singlehtml/book_sleha_techguides/bo...

И это будет работать в разы тормознее глустеря, не считая постоянной угрозы развалиться

Честно говоря согласен, pacemaker оказался очень не надежным товарищем.

gluster peer status

Number of Peers: 3

Hostname: 10.27.0.13
Uuid: 346c95aa-3387-4321-bb54-ad78ce8a1756
State: Peer in Cluster (Disconnected)

Hostname: 10.27.0.12
Uuid: a70f5483-1799-4c13-a6c9-44788be6d46f
State: Peer in Cluster (Connected)

Hostname: 10.27.0.11
Uuid: f24fc919-9540-4e03-9301-2a4cf7d303dc
State: Peer in Cluster (Connected)

gluster volume info all

Volume Name: data-***-vol
Type: Replicate
Status: Started
Number of Bricks: 2
Transport-type: tcp
Bricks:
Brick1: host4:/data/***/clustered
Brick2: host3:/data/***/clustered

Volume Name: data-vol
Type: Replicate
Status: Started
Number of Bricks: 2
Transport-type: tcp
Bricks:
Brick1: host1:/data/clustered
Brick2: host2:/data/clustered

Аргументы?

Вы просто не умеете его готовить. У меня iSCSI хранилище из двух серверов с ним работает пару лет и никаких проблем.

на суперкомпьютерах МГУ, да и не только МГУ, используется Lustre.

С чем , с Pacemaker-ом , а зачем он вам там вообще ? И да, я вот тоже про iscsi задумался, это же ведь протокол ? Как он у вас настроен\работает ?

двухлетний опыт использования drbd

У меня этот опыт побольше раза в два, что я делаю не так?

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

HNAS + HUS/HUS-VM, что вам там по производительности нужно...
Дорого.

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

Вот статью на хабре писал на эту тему: http://habrahabr.ru/post/209460/ там вроде все разжевано.

Есть такое дело, листинг директорий долгий и тормознутый , ЧЯДНТ ?

Понятия не имею, быть может не нагружаете её. У меня дрбд использовался для хранения менее трёх десятков виртуалок. Раз в месяц письмакеры взаимно думали, что ноды изолированы от кластера и самоубивались, и гораздо чаще я обнаруживал, что drbd-девайс рассинхронизировался. Всё это работало на средней скорости записи 3мб/с. С переездом на глустерь все проблемы исчезли, плюс появилась гео-репликация.

Ухты спасибо , сейчас прочитаю .

ЧЯДНТ

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

Вы с этим работали , что сказать можете ?

листинг директорий долгий и тормознутый , ЧЯДНТ ?

Умные штуки умеют метаданные хранить на быстрых дисках.

А можете носом ткнуть ,я насчет «чредующийся».

http://gluster.org/community/documentation/index.php/Gluster_3.2:_Creating_St...

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

Что-то у вас было сломано изначально. Нагрузка у меня часто под 100%, скорость репликации под 300-400Мбайт часто, ни разу за это время не было рассинхронизации DRBD и пэйсмейкре ни разу не уходил в сплит-брейн, всё работает как часы. Гасишь одну ноду - всё перетекает на вторую отлично. Виртуалок там лежит не очень много (штук 20 может), но они большие (файловые сервера).

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

Это как раз не допустимо.

Умные штуки

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

Всё это дело ессесно мониторится и если бы был какой-то косяк,то мониторинг бы сразу заорал, такие ситуации эмулировались при внедрении.

статья на шваброшвабре от 18го января, а у меня был 2010й год.

Это как раз не допустимо.

добавить ещё две ноды и сделать striped-replicated том, тогда при подыхании одной ноды всё продолжит работать, только мониторилка заорёт.

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

тогда остаётся посмотреть на ceph, pnfs и lustre, правда ceph и pnfs как бы нужен отдельный сервер метаданных,а про lustre я ничего не знаю. Ну или последовать советам слепого орацля с drbd, но тогда понадобится ещё несколько портов на свитче и пара могученьких сетевух.

Ну статью то я писал уже по итогам 2-3 летней эксплуатации.

А какой бэкенд у вашего глустеря? У меня, например, xfs поверх программного raid10 без битмапа.

Под глустером raid5 по верх ext4.