Pull to refresh

Comments 27

Такая очень опеннетовская статья, понравилось, спасибо :)
Теперь ясно, кто откликнулся на твит ^_^
Приятно было слушать доклад про вашу архитектуру на хайлоаде — желаю дальнейших успехов, и спасибо за статью.
Не знаю о чем думают маркетологи IBM, но найти информацию о ценах на их сайте нереально. Подскажите, пожалуйста, в какое кол-во зеленых выльется такое решение?
Да продают они очень смешно — цены только по запросу в ibm или к ресселлеру. Они расчитываются по непонятным космическим формулам=)
Но хотя бы порядок цены можно озвучить?
примерно 1$ это для клиента, для сервера для 1 PVU примерно 20 баксов стоит, но цена сильно зависит от того, на каком железе запущено GPFS. По какому принципу — не знаю.
там в общем-то два варианта — AIX или Linux (POWER или Intel-based).
Ну вообще-то это общепринятая практика в энтерпрайзе.
Все большие работают так, вы удивлены?
У них это называется «персональный подход к клиенту» (-:
Это очень популярная тема в продаже больших программ. потому что сейлзам хочется получить максимум того что может дать клиент. Из за этого в переговорах о покупке такого рода софта лучше прикидываться бедным валенком, вставлять в разговор названия конкурентов и вскользь упоминать опен соурс ;)
А можно сравнить ее с такими кластерными ФС как lustre и panfs?
Можно. В Lustre уже убрали затык с фиксированным кол-вом серверов метаданных?
Очепяточка — s/mmount/mmmount/. И про сборку GPL layer тоже можно было написать для начинающих. Кстати, в 3.3 прикрутили таки сборку RPM, теперь делаю make Autoconfig && make InstallImages && make rpm. Вроде бы так (пишу по памяти).
Поправил.
По поводу сборки я нечего не сказал, ибо сборкой занимался другой человек. У нас в компании для централизованой сборки пакетов используется OBS (может быть в скором времени и о нём напишем), благодоря чему на одного сотрудника ставится задание собрать пакет, а другой по завершении просто добавляет необходимый репозиторий и делает zypper in gpfs
Кстати про tiebreaker не понял. Это единственный метод держать кворум при небольшом кол-ве узлов (два-три). В этом случае обычный метод (n+1)/2 работает плохо, а диски обычно в такой конфигурации direct attached ко всем кворум-нодам.

И не надо путать кворум кластера и кворум файловых дескрипторов для конкретной файловой системы в этом кластере (если вдруг). :-)
Алексей, не могли бы вы мне помочь.

Я силюсь понять назначение Quorum в GPFS. К сожалению, везде описывают как он настраивается, по каким схемам работает и т.п. Но нигде нет описания его назначения.
Кворум — это система защиты от split-brain в распределенных системах.
Кворумом обычно называют N/2+1 машин, где N — количество машин распределенной системы

По-русски, это означает, что если одна из частей кластера видит «падение» половины и более кворумных нод она(меньшая часть кластера) завершает работу. Сделано это для того, чтобы сохранить целостность данных на ФС, ведь в теории возможна ситуация когда часть машин оказалось изолированными от сети и им нельзя ни при каких условиях писать на диск, а также читать с него, ибо данные могут быть не актуальны.
Т.е. фактически получается, что никакой дополнительной информации кворумные ноды не хранят?

В случае с tiebreaker disks проблема split-brain решается по другому. Храниться ли какая-либо информация на диске tiebreaker?
Подскажете пожалуйста, есть ли какие-либо требования по объему этих дисков? В документации по этому поводу ничего не сказано…
Похоже я разобрался.
В качестве tiebreaker диск может быть назначен любой диск, используемый в gpfs кластере. Это ни как не отражается на данных, хранящихся на этом диске.

Остается послежний вопрос — quorum это просто механизм защиты от split-brain или все-таки какая-то специфическая информация хранится на узлах назаченных кворумными?
Tiebreaker'ом лучше назначать автономную полку с дисками, подключённую к каждой quorum ноде.

По поводу кворумных нод — да это только защита от split-brain

Также у нод есть свой Designation — manager | client который определяет будет ли нода учавствовать в выборах file system и token менеджера
нужно помнить об ограничениях — кажется на текущий момент это 8 кворумных серверов при методе кворума tiebreaker. в кластерах с большим количеством кворумных узлов нужно использовать классический метод (N/2) + 1.
не хранится. но в процессе выборов на эти диски записывается информация. если failure groups в каждой fs сконфигурированы неверно, то ваша файловая система даже при живом кластере может не смонтироваться. нужно чтобы соблюдался кворум файловых дескрипторов.
Only those users with full accounts are able to leave comments. Log in, please.