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 сконфигурированы неверно, то ваша файловая система даже при живом кластере может не смонтироваться. нужно чтобы соблюдался кворум файловых дескрипторов.
Sign up to leave a comment.

Articles