Comments 33
Какая-то неприкрытая реклама, напоминающая типичный пресс-релиз. Фу.
Молодцы Red Hat развиваются стабильно.
У меня гластер не вызвал ощущения особой производительности. Возможно, я «не в тех условиях» тестировал, но в качестве высокопроизводительной СХД оно не годится.
Я вам говорю, как человек с опытом работы с ФС на больших кластерах — в крупных системах почти всегда очень большое значение имеет «тонкая настройка», т.е. по-простому «прямые руки». Поэтому, я бы на вашем месте не стал обобщать… ведь вы же на свой «страх и риск» тестировали, без официальной поддержки непосредственных разработчиков?..
У меня очень специфичные запросы — мне нужно просто ДОФИГА И ДЁШЕВО иопсов на очень рандомных данных. А так же защита от сплитбрейна, active/active конфигурация и т.д.
Если эта штука не способна выдать хотя бы 5-8к иопсов с 30 саташных винтов (при небольшом ssd-кеше), то я её бракую как «не имеющую особой производительности».
Если эта штука не способна выдать хотя бы 5-8к иопсов с 30 саташных винтов (при небольшом ssd-кеше), то я её бракую как «не имеющую особой производительности».
А не многовато хотите? Даже если взять, что диск выдает 100 iops, то получается не больше 3000 при самом оптимистичном прогнозе (страйп из всех дисков).
Не «хочу», а юзаю. Мы когда искали решение для СХД, гластер щупали в т.ч. Остановились на блочном уровне, благо там всё сильно проще.
Я всё равно, как и предыдущий автор, не понимаю как на «очень рандомных» данных (априори предполагающих бессмысленность [SSD-] кеша) вам удаётся столько иопсов выжать. Поделитесь?
Хех, ну тут всё просто, на самом деле. ssd-кеш решает главную проблему — write-random превращается в почти линейную запись (на которой SATA внезапно показывает аж 1.5k IOPS за раз, что похоже на линейную скорость записи, плюс fast rewrite, так что многие IO не доходят до SATA). С чтением сложнее, но кеш всё-таки делает свою работу.
Как это сделано… Ну, если в кратце — flashcache.
Как это сделано… Ну, если в кратце — flashcache.
Тонкая настройка != допиливание исходного кода. Одно дело крутить ручки, которые поддержка рекомендует крутить в этом конкретном случае (это если продукт не пионерский, и у него есть нормальная поддержка), а другое дело разбираться в тонкостях организации файловой системы, читать сорцы, и находить нужные настройки (хорошо, если они не в виде #define). Второй подход конечно тоже имеет право на существование, но не в энтерпрайзе.
Я поддерживал решения с хранилищем на GlusterFS. С официальной поддержкой от непосредственных разработчиков. Несколько не связанных инсталяций. GlusterFS для нас был КУЧЕЙ геморроя. Яркий представитель индусского кодопроизводства. В RH серьезные инженеры и может доведут до ума. Но я как вспомню, так взрогну.
Заглянув в релизноты появился вопрос — эта штука лишь отвечают за репликацию данных между нодами и доступ к ним, а за сохранность их на самой ноде отвечает серверный raid-контроллер?
Тоесть это не аналог ZFS, а нечто вроде DRBD+GFS?
Тоесть это не аналог ZFS, а нечто вроде DRBD+GFS?
Вообще, очень не хватает технических деталей. Хотя бы на примере существующих внедрений (где, как и для чего используют), а то получается новость одной строкой: «RH выпустил свой Storage Appliance, заходите на посмотреть».
GlusterFS работает на уровне файлов. Т.е. когда мы пишем в неё файл, он полностью записывается на один из (рандомных) нодов glusterfs. Это что-то вроде автоматического рсинка, который распределяет файлы между нодами. При необходимости можно настроить поведение так, что один файл будет писаться на несколько нод (репликация).
Клиент glusterfs работает в пользовательском пространстве (fuse).
Совокупность этих подходов даёт крайне низкую производительность. Особенно она проявляется на больших файлах и при настроенной репликации. Поэтому для серьёзных вещей glusterfs не очень пригоден. Его можно использовать лишь как очень-очень медленное, но легко масштабируемое в ширину решение.
Клиент glusterfs работает в пользовательском пространстве (fuse).
Совокупность этих подходов даёт крайне низкую производительность. Особенно она проявляется на больших файлах и при настроенной репликации. Поэтому для серьёзных вещей glusterfs не очень пригоден. Его можно использовать лишь как очень-очень медленное, но легко масштабируемое в ширину решение.
Если нужна избыточность данных на ноде, то использование софтвартного миррора (md) никто не отменял. Но вот зачем? Проще неизбыточных нод поставить избыточное количество (и это не 2*N как в случае с миррором) — дешевле выйдет. ZFS сильно прожорлив особенно по памяти, в случае с glusterfs можно обойтись достаточно дешевыми машинами с минимумом памяти.
Меня смутило, что в системных требованиях указан аппаратный рейд контроллер с батарейкой. Похоже, RH видит систему именно такой, а софтрейды в любом виде записываются в unsupported.
Удобный маркетинговый термин — «big data». Как хочешь, так и повернешь. Ровно как в этом посте, никаких данных о возможностях. Если например в изилон сразу говорят, что могут один том объемом 15 Пб делать, то здесь вообще ни о чем.
Больше всего забавляет, что определения «больших данных», как такового не существует. Есть нечто полуобъективное в википедии, с которым лично я больше всего согласен, но все вендоры трактуют это понятие как хотят. Отдельные, могут трактовать в рамках одного вендора по разному, где как удобнее с коммерческой точки зрения.
Больше всего забавляет, что определения «больших данных», как такового не существует. Есть нечто полуобъективное в википедии, с которым лично я больше всего согласен, но все вендоры трактуют это понятие как хотят. Отдельные, могут трактовать в рамках одного вендора по разному, где как удобнее с коммерческой точки зрения.
Подождите-подождите. Это ли не настоящая отказоустойчивое распределенное файловое хранилище?
У меня есть 20 серваков, в каждом по 4 локальных веника. Я хочу из этого барахла сделать сетевой аналог RAID10. Так, чтобы отказ одной машины не приводил к падению кластера.
В свое время gluster мне показался черезчур тяжелым по CPU, а Lustre не имела возможности репликации.
У меня есть 20 серваков, в каждом по 4 локальных веника. Я хочу из этого барахла сделать сетевой аналог RAID10. Так, чтобы отказ одной машины не приводил к падению кластера.
В свое время gluster мне показался черезчур тяжелым по CPU, а Lustre не имела возможности репликации.
Нихрена не понять об чём речь. Это БД, файловая система, block storage? Зачем переводить на хабр откровенно маркетинговый текст, не имеющий ничего общего с технологий?
Sign up to leave a comment.
Red Hat выходит на рынок «Big Data»