kb
27.12.2011 14:52 c8541125
Собственно, кто что о POHMELFS думает? Кто-то пробовал? http://www.opennet.ru/opennews/art.shtml...
Если не нужны возможности рейд-0 (ну, который ускоряет чтение на несколько дисков) — имеет ли смысл пробовать/смотреть?
Recommended by:
@Ts
19 comments
recommend
bookmark
subscribe
Вроде годно, оно базируется не на классических DHT с логарифмическим поиском/памятью, а на константной выборке и линейной памяти. Неэффективно для огромных сетей, но для замены NFS то, что доктор прописал.
не до конца понял. во-первых, почему в DHT логарифмический поиск/память, когда поиск вполне константный (собственно, хеш вычисляешь, по нему определяешь на каких нодах может быть данное, и берешь своё данное), и что за константная выборка и линейная память до конца не понял (если можно, кинь ссылкой). и, собственно, если яндекс.карты используют для своих миллиардов картинок, то о каком "Неэффективно для огромных сетей" может идти речь?
ну, если под константной выборкой и линейной памятью ты имел в виду O(1) и O(n) по каждому соответственно, то ничем в меня кидать не надо, просто я смысл твоего поста значит не до конца понял
на ноде не хранится список всех нод сети в обычной DHT. Здесь хранится. В обычной DHT лежит logn нод. Поиск поэтому тоже logn. Здесь нода знает о всех, поэтому поиск O(1). Где почитать на эту тему ? "A survey of peer-to-peer content distribution technologies", Theotokis, Spinellis.
Да, я имел ввиду именно символику Ландау при упоминании ассимптотической сложности, очевидно.
аа, понял, значит я не шарил и думал, что в обычной DHT хранится список всех нод. спасибо, мат.часть как-нибудь изучу
ок, а тогда можно вопрос почему неэффективно? это в том смысле, что теоретически долго добавляться нода может?
Вышел один из сети => надо дернуть таблицы у всех. Присоединился один => надо дернуть таблицы у всех. Ну и памяти много будет использоваться на хранение списка контактов.
ну, с одной стороны — да. но с другой стороны — у яндекса вон петабайт данных. то есть пусть будет это 1000 терабайтных дисков/нод. если сказать, что диск вылетает в среднем раз в месяц, то это 33 штуки в день. то есть не так уж и накладно, вроде.
Подумал, что частично фигню написал, потому что при выходе из строя одной из нод не надо ничего синхронизировать, просто при попытке записи на неё / чтения с неё должен произойти фоллбек на чтение с другой ноды, содержащей реплику нужных нам данных (т.к. эта нода упала). Ну и при замене диска нода должна с реплик данные обратно попросить и всё.
А синхронизация нужна именно при изменении конфигурации (когда добавляем / удаляем ноду). Я думал так должно всё работать.
Логично было бы использовать для чтения все доступные реплики данных, т.е. балансируя между ними нагрузку. Кроме того в таком случае нельзя будет долго забивать болт на вылетевшие диски. Алсо если, как ты посчитал, у них вылетает по 33 диска в день то им нужен коэфициент репликации 33 чтобы прожить один день комфортно. Без выходных и без сна, ибо вылетевший диск сам собой не отсинкается. Могу тебя уверить что у них есть выходные и сон.
Нагрузку балансировать таким образом, конечно, можно, но я смысла много не вижу, т.к. считаю, что и одной ноды достаточно для того, чтоб она выдержала на чтение нагрузку, а вот всё же на свежести данных мы выиграем (сначала пишется на "основную" ноду, а потом на её реплики). Плюс на каждой из нод в памяти может храниться некоторый "горячий кеш" данных этой ноды, а если рандомно разбрасывать запросы на чтение между репликами — размер памяти под горячие данные возрастает.
Не нужен им коэффициент репликации 33, потому что вероятность того, что в эти 33 диска попадут все диски из одной реплики должна быть крайне мала.
Хотя вот пишу я это всё и понимаю, что уверенно всё равно ничего не скажу, надо матчасть лучше учить.
>и одной ноды достаточно
640 килобайт достаточно. Это не аргумент для того чтобы не утилизировать имеющиеся ресурсы и не делать оптимизацию. "Свежесть данных" нам гарантирует эллиптикс своими транзакционными операциями, каким-нибудь paxos'ом.
К сожалению имею очень маленький опыт эксплуатации dfs без сервера метаданных, но почему-то я почти уверен что данные и там бьются на чанки и размазываются по всему кластеру, и в таком случае для _всех_ данных критична потеря N узлов, где N это коэфициент репликации. В противном случае там нельзя будет хранить файлы размером больше чем максимальная капасити одной ноды, так сделано в glusterfs и это весьма серьезное ограничение.
еще раз, если читать данные рандомно с одной ноды из содержащих реплику — еще не значит лучше утилизировать ресурсы. про горячий кеш я уже описал.
по поводу N дисков — если эти N дисков не покрывают полностью какую-либо из реплик — в чём проблема?
Написал тебе длинную сагу, но проебал все случайно. Вобщем посмотрел я на этот стораж на эллиптиксе.
Во-первых, да, действительно там используется одна первая реплика, остальные как стендбаи. Очень сомнительное решение, особенно неубедителен аргумент про горячий кэш. Для сторажей такого рода узким местом будет сетонька а не диск и при такой конфигурации производительность выше чем производительность одной ноды получить нельзя. Алсо, почти уверен что у них тоже аргументом было что "никому никогда не потребуется производительность выше чем производительность одного сервера". Мудилы.
Во-вторых, да, файлы там действительно хранятся целиком не разбиваясь на чанки и не размазываясь по кластеру. Это значит что хранить там файлы больше размера одной ноды нельзя. Удобно, конечно, чтобы хранить смешные картинки из инторнета дома, но в ключе 10-ти терабайтных файликов с исходными данными странное решение.
В третьих файлы там не ребалансируются сами при выпадении одной ноды/диска. Когда нода возвращается в кластер она просто спрашивает не было ли файлов для неё, при этом подразумевается что все предыдущие файлы она не потеряла. Наверное очень удобно для эксплуатации действительно больших систем где десяток нод может быть в дауне по паре недель по разным причинам.
Ну и всякие мелочи, например, при изменении конфигурации файлы ребалансируются автоматически, но на нодах где файлы больше не нужны(они больше не обслуживают этот кусок ключей) файлы не удалятся сами и их нужно удалять руками.
В целом, честно говоря, выглядит как наколеночное поделие студентов. Я бы это эксплуатировать не стал если бы у меня был выбор. Есть тыща решений более качественных для dfs — люстра, может ceph уже довели до ума, moosefs с несколькими мастерами.
Насчет первого и второго я, все же, не согласен и не считаю таким уж чем-то ужасным. Да, плохо для юз-кейсов с терабайтными файлами, да, плохо для параллельного чтения с нескольких нод, но скорость чтения с одной ноды обычно практически в сеть и упирается. В общем, какие-то юз-кейсы крайние, как по мне.
А вот третье (ребалансировка) — однозначно нужная вещь.
p.s.: скажи, а та же люстра — насколько сложна в конфигурации/поддержке?
Сразу оговорюсь что я её ниразу руками не трогал только немного документацию почитал, мы отказались от неё еще до того как начали разворачивать.
Последнее доступное ядро с люстрой 2.6.12.100 вроде(навскидку, точно не помню) это примерно 2.6.26 соответствует. Судя по всему развивать они её не планируют и в новые версии ядер тебе её придется бэкпортить самому. Собственно потому мы когда-то давно от неё отказались. Архитектурно она вроде расчитана на сторажи подключенные к нодам по multipath, т.е. потребуется специальное железо, хотя как-то иначе точно можно добится фолттолерантности в этом месте. В остальном все обычно. Все dfs с сервером метаданных примерно одинаковые.
хмм. так и что вы выбрали для dfs? просто я думаю для домашнего использования что взять чтоб заодно и попрактиковаться, пока думал можт и похмел таки
moosefs выбрали, пробовали glusterfs, pvfs и ceph, от многих отказались не попробовав. Но у нас небольшой стораж на 110тб.