LINUX.ORG.RU
ФорумAdmin

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


0

2

Доброго дня.
Интересует решение для организации кластерной системы хранения данных. Имеем:


  • два продакшен сервера
  • данные должны быть консистентны на обоих серверах в текущий момент
  • Файлы мелкие и их много (10млн)
  • Объем порядка 1-2Т
  • Данные часто дергаются , но редко модифицируются. Важна скорость чтения.


На данный момент пользуемся GlusterFs (3.2.7), но он перестал устраивать, когда файлов было не много и не очень большой объем все было хорошо, но как не пытались настройка для текущих объемов не помогает, тормозит и иногда вешает ведро. Хотелось бы чего либо с поддержкой в ядре. Что можете посоветовать , кто на чем держит распределенные данные.



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

Komintern ★★★★★ ()

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

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

MikeDM ★★★★★ ()

Вам нужен infiniband

anonymous ()
Ответ на: комментарий от MikeDM

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

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

blind_oracle ★★★★★ ()

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

blind_oracle ★★★★★ ()

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

anonymous ()
Ответ на: комментарий от pyatak123

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

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

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

pyatak123 ()
Ответ на: комментарий от anonymous

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

pyatak123 ()
Ответ на: комментарий от pyatak123

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

anonymous ()
Ответ на: комментарий от pyatak123

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

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

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

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

anonymous ()
Ответ на: комментарий от anonymous

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

pyatak123 ()
Ответ на: комментарий от anonymous

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

pyatak123 ()
Ответ на: комментарий от pyatak123

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

blind_oracle ★★★★★ ()

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

silw ★★★★★ ()
Ответ на: комментарий от blind_oracle

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

pyatak123 ()
Ответ на: комментарий от blind_oracle

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

anonymous ()
Ответ на: комментарий от anonymous

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

blind_oracle ★★★★★ ()
Ответ на: комментарий от pyatak123

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

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

cipher ★★★★★ ()
Последнее исправление: cipher (всего исправлений: 1)
Ответ на: комментарий от pyatak123

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

anonymous ()
Ответ на: комментарий от anonymous

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

pyatak123 ()
Ответ на: комментарий от blind_oracle

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

anonymous ()
Ответ на: комментарий от pyatak123

ЧЯДНТ

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

anonymous ()
Ответ на: комментарий от pyatak123

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

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

cipher ★★★★★ ()
Ответ на: комментарий от anonymous

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

blind_oracle ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

pyatak123 ()
Ответ на: комментарий от cipher

Умные штуки

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

anonymous ()
Ответ на: комментарий от blind_oracle

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

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

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

anonymous ()
Ответ на: комментарий от pyatak123

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

pyatak123 ()
Ответ на: комментарий от pyatak123

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

anonymous ()
Ответ на: комментарий от anonymous

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

blind_oracle ★★★★★ ()
Ответ на: комментарий от pyatak123

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

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.