Comments 71
>>если очень хочется, то можно
Угу, риски вы уже прописали в договоре? ;)
А на самом деле, главное в любом кластере — вовсе не проивзодительность, а устойчивость к сбоям. Думаю вам стоит уделить этому аспекту должное внимание и подробно осветить здесь.
Угу, риски вы уже прописали в договоре? ;)
А на самом деле, главное в любом кластере — вовсе не проивзодительность, а устойчивость к сбоям. Думаю вам стоит уделить этому аспекту должное внимание и подробно осветить здесь.
+4
Мы пока только экспериментируем и исследуем.
Устойчивость к сбоям — очень важный аспект, несомненно. До него дойдем, чуть позднее только. Тут довольно сложный момент получается. Любую систему можно сделать неустойчивой, все дело в нагрузке на нее. Поэтому мы решили проверить отказоустойчивость (а также пределы по нагрузке) чуть позже, после того, как будет выбран инструмент, подходящий по остальным пунктам.
У нас есть разные задачи, которые будут решены с помощью таких механизмов. Есть и некритичные данные, которые можно потерять без фатальных последствий.
Устойчивость к сбоям — очень важный аспект, несомненно. До него дойдем, чуть позднее только. Тут довольно сложный момент получается. Любую систему можно сделать неустойчивой, все дело в нагрузке на нее. Поэтому мы решили проверить отказоустойчивость (а также пределы по нагрузке) чуть позже, после того, как будет выбран инструмент, подходящий по остальным пунктам.
У нас есть разные задачи, которые будут решены с помощью таких механизмов. Есть и некритичные данные, которые можно потерять без фатальных последствий.
+3
Хм, кластер хранения для некритичных задач? Впрочем хозяин-барин ;)
А вообще очень было бы интересно взглянуть на результаты ваших тестов отказоустойчивости и стабильности в эксплуатации. Если не затруднит и не является секретом — будем ждать поста на эту тему :)
А вообще очень было бы интересно взглянуть на результаты ваших тестов отказоустойчивости и стабильности в эксплуатации. Если не затруднит и не является секретом — будем ждать поста на эту тему :)
0
Мы искали не совсем кластер хранения, если я правильно вас понимаю ) Мы искали возможность множественного монтирования read-write.
Хочется для начала достичь следующего эффекта: кластер жив и все работает хорошо и быстро. Если кластер отказал, все работает по-прежнему, но медленней (в рамках разумного) и ждет администратора, чтобы починил.
Хочется для начала достичь следующего эффекта: кластер жив и все работает хорошо и быстро. Если кластер отказал, все работает по-прежнему, но медленней (в рамках разумного) и ждет администратора, чтобы починил.
+1
Хорошо, распределенная сетевая ФС :)
Просто в своем время тоже занимался поиском подобной системы, тоже заглядывался на CEPH. Но к сожалению сам CEPH в то время был капитально нестабилен, аналоги его — только платные… Пришлось вообще отказатся от такого построения, тупо реализовав все на SMB (булыжник в огород мелкомягких).
Сейчас тоже интересно как обстоят дела у CEPH, ибо есть одна задумка в голове. Но для постоянной оценки статуса проекта просто нет ни средств ни времени. Посему надежда только на вас :)
Просто в своем время тоже занимался поиском подобной системы, тоже заглядывался на CEPH. Но к сожалению сам CEPH в то время был капитально нестабилен, аналоги его — только платные… Пришлось вообще отказатся от такого построения, тупо реализовав все на SMB (булыжник в огород мелкомягких).
Сейчас тоже интересно как обстоят дела у CEPH, ибо есть одна задумка в голове. Но для постоянной оценки статуса проекта просто нет ни средств ни времени. Посему надежда только на вас :)
0
>>Четвертые сутки стресс-тестов проходят нормально
Я конечно могу ошибаться… но 4 дня это очень маленький период для устории успеха.
Я конечно могу ошибаться… но 4 дня это очень маленький период для устории успеха.
-1
Уже около года слежу за развитием Ceph. Проект то что надо для организации бюджетного кластера виртуальных машин, так как позволяет одним и тем же серверам выступать как в роли серверов виртуализации так и OSD нодов.
Но к сожалению для использования в production система еще очень сыра и нестабильна.
Кроме того обновления (которые благо выходят регулятрно) зачастую ломают весь кластер.
Но к сожалению для использования в production система еще очень сыра и нестабильна.
Кроме того обновления (которые благо выходят регулятрно) зачастую ломают весь кластер.
0
После обновления данные тоже портятся? Или ломается только механизмы взаимодействия экосистемы Ceph, но данные можно спасти при этом?
0
От случая к случаю. Порой и данные теряются и «помогает» только mkcephfs. =(
Я несколько раз пытался перенести корпоративный фотохостинг на ceph, так как хотелось попробовать на вкус фичу, когда часто запрашиваемые данные начинают отдаваться быстрее, но после пары потерь всего хранилиша эксперементирую теперь только с /dev/zero данными =)
Я несколько раз пытался перенести корпоративный фотохостинг на ceph, так как хотелось попробовать на вкус фичу, когда часто запрашиваемые данные начинают отдаваться быстрее, но после пары потерь всего хранилиша эксперементирую теперь только с /dev/zero данными =)
0
>> I/O выдается в среднем 75 мб/с. на запись по пику
Пики как и провалу там бывают совершенно не предсказуемые.
Кстати довольно хороший прирост производительности дает вынос OSD журнала в ramfs (только для тестов) или на другой высокопроизводительный диск.
Если планируете внедрять, я бы посоветовал взглянуть на решение, когда журналы вынесены на отдельные шустрые SSD диски.
Пики как и провалу там бывают совершенно не предсказуемые.
Кстати довольно хороший прирост производительности дает вынос OSD журнала в ramfs (только для тестов) или на другой высокопроизводительный диск.
Если планируете внедрять, я бы посоветовал взглянуть на решение, когда журналы вынесены на отдельные шустрые SSD диски.
0
Как своевременно. Само мучаюсь который месяц выбором. Правда список кандидатов был несколько другой. Из перечисленных рассматривал только Ceph. Попутно поставил галочки у KVM+Sheepdog, OpenStack Swift (+остальная инфраструктура OpenStack), GlusterFS и Cloudera (в том числе из-за HDFS). Системы очень разные, но и требования были прогрессивные (помимо ФС интересовало еще и распределенная БД). Но до толковых тестов пока не дошел, так что спасибо вам хоть за какую-то информацию по Ceph.
+1
Сейчас тоже начал мучаться в аналогичных выборах. У Вас спустя год как, удалось протестировать и что-то выбрать?
Мне по описанию очень понравилась GlusterFS, думаю с неё и начать тесты.
Если у Вас появились какие-то рекомендации или новые варианты — опишите пожалуйста тут, если не сложно.
Мне по описанию очень понравилась GlusterFS, думаю с неё и начать тесты.
Если у Вас появились какие-то рекомендации или новые варианты — опишите пожалуйста тут, если не сложно.
0
Сейчас актуальная версия ceph 0.61.2-1~bpo60+1
Вкратце — из ceph мы используем активно:
radosgw: key-object хранилище аля amazonS3. Тут вопросов и нареканий нет, работает как часы. Здесь лежит контент, забирают его по http ссылкам, складывать можно тоже по http, либо напрямую тулзами для amazonS3. Очень классная штука. Мы вообще забыли, что с фоточками и прочим маленьким, но многочисленным контентом могут быть проблемы. Объектов тысяч 500, скажем.
rdb: это простой blockdevice, его можно использовать, как хранилище образов виртуальных машин, например. Надо понимать, что это, фактически, просто блочное устройство, если надо что-то разделяемое поверх, то еще надо и файлуху специальную. Тут тоже вроде все хорошо, если без фанатизма.
cephfs сейчас уже норм, но на самом деле нет )) В роадмапах говорят, что этому скоро уделят внимание, но пока, к сожалению в продакшн ее рано. Медленно и сыро. Может залипнуть, может ядро подвесить, может клиента и все намертво. Там проблемы с метаданными большие. Ну это опять же, если с фанатизмом подходить, на мелких объемах вроде все классно ))
Фанатизм, о котором я упомянул ))) Вот прямо сейчас у меня есть 150 миллионов файлов и я не совсем знаю, что дальше с ними делать )) Традиционная файлуха только работает. Остальное — не вывозит.
Глустер, конечно, цефу проигрывает по бенчам и легкости настройки и администрирования, а функционала сильно меньше.
Вкратце — из ceph мы используем активно:
radosgw: key-object хранилище аля amazonS3. Тут вопросов и нареканий нет, работает как часы. Здесь лежит контент, забирают его по http ссылкам, складывать можно тоже по http, либо напрямую тулзами для amazonS3. Очень классная штука. Мы вообще забыли, что с фоточками и прочим маленьким, но многочисленным контентом могут быть проблемы. Объектов тысяч 500, скажем.
rdb: это простой blockdevice, его можно использовать, как хранилище образов виртуальных машин, например. Надо понимать, что это, фактически, просто блочное устройство, если надо что-то разделяемое поверх, то еще надо и файлуху специальную. Тут тоже вроде все хорошо, если без фанатизма.
cephfs сейчас уже норм, но на самом деле нет )) В роадмапах говорят, что этому скоро уделят внимание, но пока, к сожалению в продакшн ее рано. Медленно и сыро. Может залипнуть, может ядро подвесить, может клиента и все намертво. Там проблемы с метаданными большие. Ну это опять же, если с фанатизмом подходить, на мелких объемах вроде все классно ))
Фанатизм, о котором я упомянул ))) Вот прямо сейчас у меня есть 150 миллионов файлов и я не совсем знаю, что дальше с ними делать )) Традиционная файлуха только работает. Остальное — не вывозит.
Глустер, конечно, цефу проигрывает по бенчам и легкости настройки и администрирования, а функционала сильно меньше.
0
У меня задача — сделать распределенное хранилище бекапов, поэтому скорость тут не особо важна, главное надежность и минимальный геморрой в настройке и поддержке.
И очень хотелось бы чтобы была система снапшотов, чтобы можно было получить бекап файла например недельной давности, без заморачивания с инкрементальной системой бекапов.
Сейчас все это работает на зеркальном рейде хардварном и ZFS со снапшотами, но на каждом сервере отдельно. Хочется сделать общее хранилище.
Какой вариант для этого порекомендуете?
И очень хотелось бы чтобы была система снапшотов, чтобы можно было получить бекап файла например недельной давности, без заморачивания с инкрементальной системой бекапов.
Сейчас все это работает на зеркальном рейде хардварном и ZFS со снапшотами, но на каждом сервере отдельно. Хочется сделать общее хранилище.
Какой вариант для этого порекомендуете?
0
Есть ещё вот такой вариант: www.gluster.org/community/documentation/index.php/GlusterOnZFS — попробую может его настроить.
0
я бы не рекомендовал ))
zfs работает мягко говоря ниочень ))) Gluster тоже, в связке будет наверное бомба, только в плохом смысле этого слова _)
zfs работает мягко говоря ниочень ))) Gluster тоже, в связке будет наверное бомба, только в плохом смысле этого слова _)
0
А какой вариант тогда порекомендуете? ;)
zfs на солярисе вроде уже годами отточен в работе, так что взорваться не должен по-идее.
Ещё вычитал вариант зеркалирования через DRBD — но минус в том что нужно 2 одинаковых раздела на разных компах, а 3 штуки и более уже не получится объединить в одну помойку, только парами ;(
zfs на солярисе вроде уже годами отточен в работе, так что взорваться не должен по-идее.
Ещё вычитал вариант зеркалирования через DRBD — но минус в том что нужно 2 одинаковых раздела на разных компах, а 3 штуки и более уже не получится объединить в одну помойку, только парами ;(
0
А попробуйте ceph ) Я туда бекаплюсь сейчас.
Любой вариант вам подойдет, но мне нравятся те, где место можно расширять без заморочек.
Любой вариант вам подойдет, но мне нравятся те, где место можно расширять без заморочек.
0
А в ceph есть какой-то механизм снапшотов? По снапшотам мне очень понравилась ZFS и BTRFS — просто делаешь rsync нужных файлов и ежедневные/еженедельные снимки, и потом за любую дату открываешь снапшот и берешь файло. Безо всяких дополнительных скриптов, архивов, систем и т.п.
Хочется вот прям тоже самое, но на распределенном хранилище с двойным дублированием данных.
Хочется вот прям тоже самое, но на распределенном хранилище с двойным дублированием данных.
0
Вы мне скажите: зачем вам POSIX-совместимость?
Стоьлко проблем исчезает, если от неё отказаться.
Стоьлко проблем исчезает, если от неё отказаться.
0
permissions, acl, inotify. Безопасность, совместимость с локальными файловыми системами, гибкость.
Понятно, что у специализированных файловых систем совместимость зачастую не полная. Разработчики не должны писать код, заточенный под систему, которую мы предоставляем и который в другой может не заработать.
Также если кластер развалится, придется работать с локальными файловыми системами и хочется не заботиться о совместимости на системном уровне с точки зрения приложения.
Альтернатив мы пока не нашли все равно )))
Понятно, что у специализированных файловых систем совместимость зачастую не полная. Разработчики не должны писать код, заточенный под систему, которую мы предоставляем и который в другой может не заработать.
Также если кластер развалится, придется работать с локальными файловыми системами и хочется не заботиться о совместимости на системном уровне с точки зрения приложения.
Альтернатив мы пока не нашли все равно )))
0
> GPFS, Lustre и прочие файловые системы, а также надстройки, мы не рассматривали в этот раз
GPFS зря не рассматривали, имею положительный опыт. Поднимается и настраивается где-то за полчаса. Производительность и масштабируемость великолепные (у нас до 8 ГБ/с IO выжимает).
Единственный минус это закрытость. Плюс из коробки имеем HSM, если на него лицензию приобресть.
GPFS зря не рассматривали, имею положительный опыт. Поднимается и настраивается где-то за полчаса. Производительность и масштабируемость великолепные (у нас до 8 ГБ/с IO выжимает).
Единственный минус это закрытость. Плюс из коробки имеем HSM, если на него лицензию приобресть.
0
Насколько я помню, это поддерживается из коробки в RedHat Advanced Server and SuSE Enterprise Server. В debian-based дистрибутивах придется поплясать краковяк, гопак и польку сразу, чтобы все заработало )))
a.silenkov@uk-rnd-32:~$ apt-cache search gpfs | wc -l
0
Да и отыскать что-либо вменяемое в документации IBM быстро не получится при случае. Blade center мы, например, неделю запускали, пока 300 листов документации не прочитали, скачав стопицот файлов, прошивок, утилит, так и стоял как кирпич.
a.silenkov@uk-rnd-32:~$ apt-cache search gpfs | wc -l
0
Да и отыскать что-либо вменяемое в документации IBM быстро не получится при случае. Blade center мы, например, неделю запускали, пока 300 листов документации не прочитали, скачав стопицот файлов, прошивок, утилит, так и стоял как кирпич.
+1
Они предоставляют RPM-пакеты, поэтому про дебиан ничего удивительного. Так-то там нужно собрать модуль ядра, поставить ksh и конвертнуть в deb. В теории. Как-нибудь попробую на практике, есть такая необходимость тоже.
Не думаю что им именно Advanced Server надо, но в RedHat действительно чувствует себя хорошо. Документация на GPFS вполне вменяемая, нарекания вызывает сам сайт IBM, ибо там реально черт ногу сломит :)
Не думаю что им именно Advanced Server надо, но в RedHat действительно чувствует себя хорошо. Документация на GPFS вполне вменяемая, нарекания вызывает сам сайт IBM, ибо там реально черт ногу сломит :)
0
Да, с OpenVZ вполне совместимо, также имею опыт совместного использования.
0
А чем вам не подошел бы nfs4-pnfs? Самые старые и самые зарекомендовавшие себя системы. Решение даже слишком простое но очень эфективное
+1
А если делать просто файлопомойку на кучу терабайт — 500-600, к которой не предьявляется особых требований по производительности — т.е. просто видеоархив, к примеру — то Ceph для этого подойдёт?
Я вот сейчас думаю над относительно дешёвым решением, которое бы позволило подключаться обычным виндовым машинам и неспешно сливать файлики в случае необходимости. Скорость некритична, но вот устойчивости к смерти пары-тройки винтов хотелось бы. Что порекомендуете ещё посмотреть?
Я вот сейчас думаю над относительно дешёвым решением, которое бы позволило подключаться обычным виндовым машинам и неспешно сливать файлики в случае необходимости. Скорость некритична, но вот устойчивости к смерти пары-тройки винтов хотелось бы. Что порекомендуете ещё посмотреть?
0
Посмотрите RAID
-1
Спасибо, но я имел ввиду именно кластерное решение. RAID6 на 12TB у каждого узла у меня есть. Но таких узлов у меня 10-20-30. Вот именно их я и хочу объединить так, чтобы для любой виндовой монтажки оно тупо виделось как сетевой диск. Не 30 дисков, а именно один.
+2
Есть вобщем масса готовых хардварных решений которые решают эту задачу на блочном уровне. Т.о. позволяет ставить на себя любую FS.
Например раз и два от dell, или более хитрый (и весьма недешевый) вариант от конкурентов со своей встроенной фс три. Последний активно используем сами, не первый год, полет нормальный
Например раз и два от dell, или более хитрый (и весьма недешевый) вариант от конкурентов со своей встроенной фс три. Последний активно используем сами, не первый год, полет нормальный
0
Вы невнимательно читали мой начальный пост — речь идёт о _недорогом_ (как некоторые любят выражаться — «из г… на и палок») решении. Хардварное решение на 500-600 ТЕРАбайт от ЛЮБОГО бренда будет стоить столько, что за эти деньги проще на кассеты писать заставить сотню маленьких обезьянок.
-2
Спасибо за статью! Будет очень интересно узнать о проблемах и решениях, которые появятся после длительной эксплуатации.
0
Кстати, для хранилища можно использовать вот такую железяку bitblaze.ru/configuration.html, и организовать мощное облако. Причем каждый диск видится отдельно, т.е. не мешают рулить дисками всякие там хардверные рейды.
0
А что, у вас есть богатый опыт практического использования сей чудной «вундервафли»?
0
По сути это обычный самосбор.
У меня стоит самосборный сервер под хранилище, переделанный из брендового 1у сервера, и работает как часы.
И все обошлось в раза 4 дешевле этого чуда.
У меня стоит самосборный сервер под хранилище, переделанный из брендового 1у сервера, и работает как часы.
И все обошлось в раза 4 дешевле этого чуда.
0
а я купил себе неттоп на атоме, он мне обошелся дешевле чем этот 1U
0
На атоме? ), как то не серьезно. Хотя, все от задач зависит.
0
Шучу, шучу. Просто я про то, что не стоит говорить что 1U дешевле чем 4U сервер хранения на 45 дисков + 4 под систему, который стоит 80 т.руб. «только добавь винты»
0
Не, вы меня не так поняли.
Я взял 1у сервер и перенес его потроха в 4у сервер, докинул контроллеров и дисков. Там мать p5000 кажись стоит и процы 54 хеоны, это шоколадная начинка для сана то. В этой железке за 80к такой же набор железа, только стоит она раза в 2 дороже.
Я взял 1у сервер и перенес его потроха в 4у сервер, докинул контроллеров и дисков. Там мать p5000 кажись стоит и процы 54 хеоны, это шоколадная начинка для сана то. В этой железке за 80к такой же набор железа, только стоит она раза в 2 дороже.
0
Что значит докинул дисков? Если сравнивать сервера, хранения то нужно учитывать категории. Сколько у вас дисков?
0
8, по 4 на контроллере. Можно и больше, но мне не нужно.
Самосбор рамок не имеет )
Самосбор рамок не имеет )
0
У нас не самосбор, мы модифицировали схемы и корпуса. Но речь не об этом, а о том что говорить мои 8 дисков дешевле ваших 45 как-то нецелесообразно.
0
А вы не пробовали LVM Cluster?
0
Что по поводу GlusterFS?
+2
Здесь очень сложно все, например с приоритетами по I/O. FUSE не очень хорошо работает под нагрузкой. Если у нас нет ресурсов на юзерлевел, то все встает колом сразу ))
0
Зачем вам FUSE? используйте нативный клиент.
Ну или на худой конец GlusterFS работает в режиме NFS или о боже! CIFS +)
Есть примеры уже 1С на GlusterFS (Патчи разработчикам GlusterFS вроде как активно отправлялись)
Меня смущают другие две вещи:
1) Что нода обнавляется только при обращение к ней, тут я вижу много праблем.
Можно конечно прописать в кроне ls но это мягко говоря костыль :)
2) Проблема с Масштабируемость. Так как определенная роль отводится и клиенту в GlusdterFS, то при небольшом кол-ве клиентов и большом кол-ве нод, может понизится скорость! (По крайне мере если я все правильно понял)
Ну или на худой конец GlusterFS работает в режиме NFS или о боже! CIFS +)
Есть примеры уже 1С на GlusterFS (Патчи разработчикам GlusterFS вроде как активно отправлялись)
Меня смущают другие две вещи:
1) Что нода обнавляется только при обращение к ней, тут я вижу много праблем.
Можно конечно прописать в кроне ls но это мягко говоря костыль :)
2) Проблема с Масштабируемость. Так как определенная роль отводится и клиенту в GlusdterFS, то при небольшом кол-ве клиентов и большом кол-ве нод, может понизится скорость! (По крайне мере если я все правильно понял)
0
плюсую вопрос!
накатил GlusterFS на тестовом кластере(proxmox+KVM) из 4-х нод, нагрузка не очень высокая, но работает стабильно. (правда конечно не продакшен задачи крутятся)
накатил GlusterFS на тестовом кластере(proxmox+KVM) из 4-х нод, нагрузка не очень высокая, но работает стабильно. (правда конечно не продакшен задачи крутятся)
0
Мы хотим внедрить opennebula или cloudstack (то же тестировать надо)
Причем GlusterFS сделать именно как резер с СХД FiberChannel (СХД у нас сейчас точка отказа, пусть скорость при переключении на GlusterFS упадет, но будет худо бедно работать)
Реальной пока замены на текущий момент не приметел, надо тестировать!
Причем GlusterFS сделать именно как резер с СХД FiberChannel (СХД у нас сейчас точка отказа, пусть скорость при переключении на GlusterFS упадет, но будет худо бедно работать)
Реальной пока замены на текущий момент не приметел, надо тестировать!
0
Если не сложно, можно подробней про конфигурацию. С какой целью будет использоваться GlusterFS, что на ней будет лежать?
Мы, к примеру, использовали следующую конфигурацию. Кратенько из серии #мывсеумрем ))
1. БД — два инстанса postgres в master-slave репликации
2. Веб-приложение — два инстанса. Внутри nginx+php-fpm, общий каталог с некоторым количеством кода.
3. Сфинкс+индексатор — два инстанса с общим каталогом индексов,
Веб1 ломится в бд1 и в сфинкс1, веб2-бд2-сфинкс2.
Запускаем нагрузку tsung. Параметры нагрузки такие же, как и в случае использования локальных файловых систем. Получаем дикие тормоза при использовании любой системы, которая FUSE.
— БД начинает мощно забирать ресурсы CPU и I/O,
— всем user level процессам система говорит «подождите чуть-чуть, я пока занята на system level, сейчас закончу, дойдем до вас». Время реакции везде увеличивается, время отклика везде увеличивается
— хранилище замерзает, время доступа к нему возрастает.
— бекенд, который использует разделяемый код, начинает затуплять, 500ые
— сфинксы оба тоже затупляют, увеличивается время ответа сервиса, 500ые
— затупляет бд slave, который тоже быстро хочет актуальных данных. Их нет из-за ресурсов, которые тратят сервисы, пытающиеся достучаться до замершего хранилища. Растет replication lag, веб2 сыпет 500ми, но по-прежнему тратит процессорное время и I/O.
Все разделяемое вроде бы на месте, но очень долго читается, сервисы считают, что ничего не работает.
Ядро со своими планировщиками в панике, начинается чехарда с дикими переключениями контекстов, нелинейно растет load average, затупление приобретает характер снежной лавины ))
Выключаем tsung, все работает стабильно, ничего не потерялось, сервис работоспособен и шустро отдает контент. Страшный сон администратора! )))
Мы, к примеру, использовали следующую конфигурацию. Кратенько из серии #мывсеумрем ))
1. БД — два инстанса postgres в master-slave репликации
2. Веб-приложение — два инстанса. Внутри nginx+php-fpm, общий каталог с некоторым количеством кода.
3. Сфинкс+индексатор — два инстанса с общим каталогом индексов,
Веб1 ломится в бд1 и в сфинкс1, веб2-бд2-сфинкс2.
Запускаем нагрузку tsung. Параметры нагрузки такие же, как и в случае использования локальных файловых систем. Получаем дикие тормоза при использовании любой системы, которая FUSE.
— БД начинает мощно забирать ресурсы CPU и I/O,
— всем user level процессам система говорит «подождите чуть-чуть, я пока занята на system level, сейчас закончу, дойдем до вас». Время реакции везде увеличивается, время отклика везде увеличивается
— хранилище замерзает, время доступа к нему возрастает.
— бекенд, который использует разделяемый код, начинает затуплять, 500ые
— сфинксы оба тоже затупляют, увеличивается время ответа сервиса, 500ые
— затупляет бд slave, который тоже быстро хочет актуальных данных. Их нет из-за ресурсов, которые тратят сервисы, пытающиеся достучаться до замершего хранилища. Растет replication lag, веб2 сыпет 500ми, но по-прежнему тратит процессорное время и I/O.
Все разделяемое вроде бы на месте, но очень долго читается, сервисы считают, что ничего не работает.
Ядро со своими планировщиками в панике, начинается чехарда с дикими переключениями контекстов, нелинейно растет load average, затупление приобретает характер снежной лавины ))
Выключаем tsung, все работает стабильно, ничего не потерялось, сервис работоспособен и шустро отдает контент. Страшный сон администратора! )))
0
да… представил картину, именно как «снежная лавина».
У меня задачи кластера другие — на каждой ноде лежит реплика GlusterFS, на которой в свтою очередь крутятся виртуальные машины (KVM)
Т.е. каждая нода выполняет опред. кол-во VM, образы которых лежат на «общем» разделе glusterfs.
Пока всего по паре VM на каждой ноде, и нагрузка небольшая (под рукой щас нет цифр), возможно поэтому, user space специфика glusterfs пока не проявляется.
ps — После вашего комента(спасибо кстати за подробное описание лагов) и сабжевой статьи начинаю смотреть на CEPF
У меня задачи кластера другие — на каждой ноде лежит реплика GlusterFS, на которой в свтою очередь крутятся виртуальные машины (KVM)
Т.е. каждая нода выполняет опред. кол-во VM, образы которых лежат на «общем» разделе glusterfs.
Пока всего по паре VM на каждой ноде, и нагрузка небольшая (под рукой щас нет цифр), возможно поэтому, user space специфика glusterfs пока не проявляется.
ps — После вашего комента(спасибо кстати за подробное описание лагов) и сабжевой статьи начинаю смотреть на CEPF
0
Уберите FUSE!
Вот сравнение с NFS и GlusterFS, где то видел сравнение с lustre
www.gluster.com/community/documentation/index.php/GlusterFS_3.0.4_cluster/replicate_vs_NFSv3_Benchmark
На текущий моментмы планируем использовать как резер виртуальных машин лежащих на СХД.
Хотя конечно лично мне интересно пощупать ее для nginx и mysql. (С Mysql было много проблем, вроде бы их решили)
В общем надо тестировать, и да! не используйте FUSE :)
Вот сравнение с NFS и GlusterFS, где то видел сравнение с lustre
www.gluster.com/community/documentation/index.php/GlusterFS_3.0.4_cluster/replicate_vs_NFSv3_Benchmark
На текущий моментмы планируем использовать как резер виртуальных машин лежащих на СХД.
Хотя конечно лично мне интересно пощупать ее для nginx и mysql. (С Mysql было много проблем, вроде бы их решили)
В общем надо тестировать, и да! не используйте FUSE :)
0
Нативный клиент тоже в userspace и тоже FUSE)) Я не говорю, что это плохо. Плюсов у такого решения много. Но это не всем подходит. NFS, CIFS нам не подходят тоже. Нагрузки слишком велики.
0
The final volume may then be mounted by the client host through the FUSE mechanism or accessed via libglusterfs client library without incurring FUSE filesystem overhead.
0
Да еще добавлю что:
Note: This method of accessing GlusterFS does not completely conform to POSIX standards.
Опять же надо читать, что они именно там не все поддерживают в POSIX.
Note: This method of accessing GlusterFS does not completely conform to POSIX standards.
Опять же надо читать, что они именно там не все поддерживают в POSIX.
0
Спасибо, изучим. Я не знал про libglusterfs )
0
Кстати, под ваши нужды можно посмотреть проект eblob.ru
0
Скажите а как можно организовать общее хранилище из нескольких физических?
Т.е. у меня есть 2 машины, я хочу их видеть не как 2 отдельных хранилища, а как одно. И в дальнейшем наращивать бес проблемно количество машин.
Т.е. у меня есть 2 машины, я хочу их видеть не как 2 отдельных хранилища, а как одно. И в дальнейшем наращивать бес проблемно количество машин.
0
Как ощущения после полугода использования? Система стабильна?
0
Sign up to leave a comment.
Выбор распределенной файловой системы для Linux. Пару слов о Ceph и остальных