Comments 61
Вопрос немного не в тему но как связаны Cocaine и Elliptics, с Яндексом и reverbrain.com/ это ваша дочерняя организация, или просто сотрудничаете, или вы их купили?
Как один из вариантов: бывшие разработчики организовали свою команду и продолжили проект…
или reverbrain просто на основе открытых исходников, строят свою модификацию под Амазон.
Сравнивать исходники Эклиптика и Кокаина — просто нет времени…
или reverbrain просто на основе открытых исходников, строят свою модификацию под Амазон.
Сравнивать исходники Эклиптика и Кокаина — просто нет времени…
Cocaine и Elliptics — это open-source, права на код написаны в заголовке каждого файлика, то есть права на эти программы принадлежат конкретным людям. Вообще, и Elliptics, и Cocaine начинались как pet-project Жени Полякова и Андрея Сибирёва соответственно, а уже потом в них (на ранней стадии, прошу заметить) увидели перспективу и начали применять внутри компании.
А reverbrain.com — это сообщество людей, которые пишут Elliptics. Сайт создавался как площадка, на которой мы делимся знаниями с пользователями.
А reverbrain.com — это сообщество людей, которые пишут Elliptics. Сайт создавался как площадка, на которой мы делимся знаниями с пользователями.
Описан riakdb, как он есть. Чем ваша система лучше?
Очевидно, что эти системы имеют много общего, так как обе были написаны под воздействием драфта Amazon Dynamo, опубликованного в далеком 2006 году.
А теперь по пунктам:
Это то, насколько мне известно, что у Riak плохо. Но для проведения более детального сравнения нужен кто-нибудь, кто очень хорошо разбирается в Riak, тогда мы готовы побеседовать :) Так же мы готовы пострелять и сравнить обе системы в плане производительности
А теперь по пунктам:
- У Riak более-менее нормальная кросс-датацентровая репликация данных есть только в платной версии
- Насколько мне известно, в Riak странно устроена репликация данных. Все машины там пронумерованы, причем каждая, например, двойка подряд идущих машин хранит свою часть кольца. Поэтому если добавить машину «как-то не так», то произойдет почти полная перекачка всех данных внутри дата-центра. Так же это накладывает ограничение на количество добавляемых машин, их количество должно быть кратным количеству копий
- Backend Riak'а потребляет гораздо больше памяти, чем наш eblob
- Riak написан на Erlang, как правило, вам будет очень сложно понять что идет не так и попробовать это исправить :)
Это то, насколько мне известно, что у Riak плохо. Но для проведения более детального сравнения нужен кто-нибудь, кто очень хорошо разбирается в Riak, тогда мы готовы побеседовать :) Так же мы готовы пострелять и сравнить обе системы в плане производительности
Да, всё так. Кросс-датацентровую репликацию я не пробовал, потому что и риак сам по себе не устроил. Перебиваемся couchdb пока.
Про оптимизацию добавления машин в кольцо были сообщения, вроде как.
Потребление памяти не знаю, не смотрел.
Ок, а как у вас обстоят дела с решением конфликтов после split brain? Векторные часы, просто часы, как в монго ( :) ), или еще что?
Про оптимизацию добавления машин в кольцо были сообщения, вроде как.
Потребление памяти не знаю, не смотрел.
Ок, а как у вас обстоят дела с решением конфликтов после split brain? Векторные часы, просто часы, как в монго ( :) ), или еще что?
Ок, а как у вас обстоят дела с решением конфликтов после split brain?
Есть несколько подходов:
- Просто часы, это подходит в большинстве случаев
- Можно построить свои векторные часы на основе примитивов Elliptics, например, с помощью Lookup и атомарного Compare&Swap (в таком случае главную роль играет sha512 чексумма данных)
- А можно отдавать только те данные, которые ближе :) Это корректно, когда мы точно знаем, что данные не переписываются, а отдавать их нужно как можно быстрее
> Riak написан на Erlang, как правило, вам будет очень сложно понять что идет не так и попробовать это исправить :)
Я бы еще сказал, что как правило это значит, что он очень медленный (в сравнении с другими). Правда, смотрел относительно давно, конечно.
Я бы еще сказал, что как правило это значит, что он очень медленный (в сравнении с другими). Правда, смотрел относительно давно, конечно.
> Насколько мне известно, в Riak странно устроена репликация данных.
Нормально там репликация устроена. Точно не так, как у вас написано. И ограничений таких нет на количество добавляемых машин. В общем, весь пункт не соответствует действительности.
> Riak написан на Erlang, как правило, вам будет очень сложно понять что идет не так и попробовать это исправить :)
Для многих Erlang плюс, потому что в плюсах копаться мочи уже нет. А риак код — он маленький, как на ладони.
Нормально там репликация устроена. Точно не так, как у вас написано. И ограничений таких нет на количество добавляемых машин. В общем, весь пункт не соответствует действительности.
> Riak написан на Erlang, как правило, вам будет очень сложно понять что идет не так и попробовать это исправить :)
Для многих Erlang плюс, потому что в плюсах копаться мочи уже нет. А риак код — он маленький, как на ладони.
А вы умеете правильно готовить Riak? Было бы интересно сравнить: позаливать много данных, посмотреть, как ведёт себя при потере ДЦ или диска, при сбоях сети, как восстанавливается и т.д.
Машинки и инструменты для нагрузочного тестирования у нас есть.
Машинки и инструменты для нагрузочного тестирования у нас есть.
У нас 50-хостовый кластер риака стоял несколько лет. Сейчас ужали до 17-нодного. Данных — несколько сотен гигабайт, не терабайты.
Сбоев было много (работаем поверх EC2, довольно часто вылетают хосты), восстанавливается практически всегда нормально, но однажды на два дня потеряли часть данных (пока делали восстановление InnoDB структуры), после пары лет работы (но версия была старая).
Сейчас работаем с LevelDB-бэкендом, полёт нормальный. Кросс-датацентр-репликацию не используем.
Также см. lionet.livejournal.com/tag/riak
Сбоев было много (работаем поверх EC2, довольно часто вылетают хосты), восстанавливается практически всегда нормально, но однажды на два дня потеряли часть данных (пока делали восстановление InnoDB структуры), после пары лет работы (но версия была старая).
Сейчас работаем с LevelDB-бэкендом, полёт нормальный. Кросс-датацентр-репликацию не используем.
Также см. lionet.livejournal.com/tag/riak
Лев Валкин, это ты? :) Мы с тобой после Стачки в Ульяновске общались пол года назад, ты обещал eblob попробовать.
Просто хранить записи, особенно когда они в памяти помещаются — элементарно. Когда появляются географически разнесённые ДЦ, количество записей становится большим, да и вообще к машинам подключены полки на 24-48 дисков — всё становится сложнее и интереснее. Когда же из такой конструкции начинаем пытаться выжимать максимум по производительности, то тут нужны очень хорошие знания о внутреннем устройстве системы и её конфигурации.
Хорошим примером кажущейся простоты является MongoDB. Пока нагрузка не слишком большая и данных относительно мало — она правда работает без особых проблем.
Просто хранить записи, особенно когда они в памяти помещаются — элементарно. Когда появляются географически разнесённые ДЦ, количество записей становится большим, да и вообще к машинам подключены полки на 24-48 дисков — всё становится сложнее и интереснее. Когда же из такой конструкции начинаем пытаться выжимать максимум по производительности, то тут нужны очень хорошие знания о внутреннем устройстве системы и её конфигурации.
Хорошим примером кажущейся простоты является MongoDB. Пока нагрузка не слишком большая и данных относительно мало — она правда работает без особых проблем.
Хостим нечто подобное на Cassandra, около 50 нод, больше 100 терабайт. Опыт накоплен огромный, анализ Heap дампов, кодовой базы, фиксы. Было бы интересно сравнить плюсы и минусы с Riak, обслуживающим подобную конфигурацию.
По поводу «правильно готовить»: это не хадуп, чтобы его долго настраивать. Риак запускается за несколько минут, особых проблем при запуске не вызывает. Так что не знаю, как я могу помочь его приготовить.
Riak обладает фатальным недостатком.
Кокаин, мулька… Яндекс знает толк в веществах.
Интересно, а только мне одному картинка Elliptics напомнила очертания суперкомпьютера из детской книжки «А я был в Компьютерном Городе»? :)
Сразу прошу прощения за занятое место на экране, но тег спойлер почемуто не работает…
Сразу прошу прощения за занятое место на экране, но тег спойлер почемуто не работает…
Это Cray-1. Один из первых суперкомпьютеров.
Что делаете с нагрузкой на базу хешей файлов? Насколько я понимаю такая база должна быть централизованной. Какие нагрузки (запрос/сек) реально вы испытывали?
Спасибо!
Спасибо!
У нас нет никакой базы хешей файлов, поэтому никакую нагрузку на нее мы не испытываем.
Хотя, может, я и некорректно понял ваш вопрос, не могли бы вы его пояснить?
Хотя, может, я и некорректно понял ваш вопрос, не могли бы вы его пояснить?
Когда приходит запрос на файл как вы определяете на каком сервере он лежит?
Примерно так:
Поэтому ответ на этот вопрос всегда можно дать за O(1) из любого места Elliptics Network.
- Мы считаем sha512 от имени файла, получаем соответствующий записи ключ
- У нас всегда есть свежая таблица маршрутизации для всех групп, в ней мы храним только начала секторов, принадлежащих машине, поэтому она имеет небольшой размер и спокойно помещается в памяти
- По таблице маршрутизации за O(1) всегда можно узнать для каждой из групп где должен лежать файл
Поэтому ответ на этот вопрос всегда можно дать за O(1) из любого места Elliptics Network.
А файлы вы храните целиком на одном сервере? Это же не эффективно будет для очень маленьких и очень больших фалов.
Мы достаточно эффективно храним файлы размером от единиц килобайт до нескольких гигабайт. На диске данные хранятся в блобах, как правило, по несколько миллионов ключей в файле.
С данными большего объема теоретически могут возникнуть проблемы, но тестирований еще не проводили, да и нужды не было.
С данными большего объема теоретически могут возникнуть проблемы, но тестирований еще не проводили, да и нужды не было.
Мне кажется логичнее было бы хранить данные кусками фиксированного размера. Большие файлы дробить, а маленькие объединять. В вашей текущей архитектуре будет вам будет тяжело рахбираться с миллиардами маленьких файлов и большими файлами в несколько террабайт. Куски фиксированного размера позволят эффективнее использовать дисковое пространство на сервере и повысят производительность (TPS) при доступе к большим файлам.
У вас практические знания с цифрами?
Нам очень легко разбираться с файлами, мы не обращаем внимание на размер. У нас есть большое преимущество перед файловыми системами — мы заранее знаем, какой будет размер записи, и применяем наиболее эффективный метод записи — append записи в конец большого блоба. В итоге мы максимально эффективно используем дисковое пространство, оверхэд составляют только служебные заголовки. При этом мы минимизируем количество random seek, запись превращается в линейную. Мы не испытываем никаких проблем с фрагментацией, которые обязательно возникнут при попытке запихать несколько мелких записей в блок. И ещё надо где-то держать список пустых блоков.
Что касается чтения — если вы начинаете хранить файл кусками, вам сразу надо придумывать механизм склеивания этих кусков, какой-то мэппинг. При обращении к файлу вам надо делать +1 seek, чтобы поднять файл мэппинга, и линейное чтение превращается в уже не столь линейное. При записи придётся синхронизировать запись блока и обновление маппинга, желательно делать это атомарно с точки зрения клиента. Конечно, у такой схемы есть и плюсы: не надо проводить большую дефрагментацию блобов, можно хранить неограниченно большие файлы.
Для раздачи больших файлов мы научили nginx раздавать их непосредственно из блобов, и тут запись одним куском идеально подходит и сильно упрощает процесс.
А сейчас я расскажу немножко о магии. В Elliptics есть возможность запускать server-side скрипты непосредственно на той ноде, где лежат данные. То есть, если действительно есть большая необходимость хранить файлы кусками, то это можно сделать, написав не очень большую программу на языке, поддерживаемом Cocaine: C++, Python, Java, Javascript. Вы будете отправлять запись на ноду в этот скрипт, а он уже будет разбираться с мэппингом, записью в правильный блок (блок при этом записывается как обычная запись), склеиванием блоков при чтении.
Нам очень легко разбираться с файлами, мы не обращаем внимание на размер. У нас есть большое преимущество перед файловыми системами — мы заранее знаем, какой будет размер записи, и применяем наиболее эффективный метод записи — append записи в конец большого блоба. В итоге мы максимально эффективно используем дисковое пространство, оверхэд составляют только служебные заголовки. При этом мы минимизируем количество random seek, запись превращается в линейную. Мы не испытываем никаких проблем с фрагментацией, которые обязательно возникнут при попытке запихать несколько мелких записей в блок. И ещё надо где-то держать список пустых блоков.
Что касается чтения — если вы начинаете хранить файл кусками, вам сразу надо придумывать механизм склеивания этих кусков, какой-то мэппинг. При обращении к файлу вам надо делать +1 seek, чтобы поднять файл мэппинга, и линейное чтение превращается в уже не столь линейное. При записи придётся синхронизировать запись блока и обновление маппинга, желательно делать это атомарно с точки зрения клиента. Конечно, у такой схемы есть и плюсы: не надо проводить большую дефрагментацию блобов, можно хранить неограниченно большие файлы.
Для раздачи больших файлов мы научили nginx раздавать их непосредственно из блобов, и тут запись одним куском идеально подходит и сильно упрощает процесс.
А сейчас я расскажу немножко о магии. В Elliptics есть возможность запускать server-side скрипты непосредственно на той ноде, где лежат данные. То есть, если действительно есть большая необходимость хранить файлы кусками, то это можно сделать, написав не очень большую программу на языке, поддерживаемом Cocaine: C++, Python, Java, Javascript. Вы будете отправлять запись на ноду в этот скрипт, а он уже будет разбираться с мэппингом, записью в правильный блок (блок при этом записывается как обычная запись), склеиванием блоков при чтении.
Знаний с цифрами у меня тлоько про наш конкретный слуйчай, как он к вашему относится не очень понятно. В общем Вы все правильно написали про плюсы и минусы. Еще только про одну вещь я бы все таки подумал общая пропускная способность системы. Если доступ идет одновременно к ограниченному количеству файлов по сравнению с общим объемом хранимых данных, то получается выгоднее файлы разбивать на куски и разбрасывать их по серверам. Типа торрента чтобы получалось. Тогда получается максимально задействовать все головки дискови повысить общую пропускную способность хранилища.
Как правило при передачи больших файлов упираемся не в диск, а в сеть. Вот смотрим: один диск в состоянии читать данные со скоростью, допустим, 100 мегабайт в секунду, сеть, как правило, стоит гигабитная, то есть почти такая же.
Более того, на каждой машине стоит полка из нескольких десятков дисков, что уже многократно перекрывает возможности даже десятигигабитной сети.
Как бы мы не разносили файл на разные машины — мы все равно не сможем его отдать быстрее.
Так же стоит отметить, что на наших задачах файлов, как правило, очень много, поэтому поэтому к машинам обращаются более-менее равномерно.
Более того, на каждой машине стоит полка из нескольких десятков дисков, что уже многократно перекрывает возможности даже десятигигабитной сети.
Как бы мы не разносили файл на разные машины — мы все равно не сможем его отдать быстрее.
Так же стоит отметить, что на наших задачах файлов, как правило, очень много, поэтому поэтому к машинам обращаются более-менее равномерно.
Шикарно живете :) Диски по 100Мб/сек и полки на несколько десятков дисков на каждом сервере. Я в более общем случае рассуждал, когда диски медленные и сервера слабенькие могут быть, а производительность все равно нужна высокая. Плюс иногда бывает нужен не весь файл, а его кусочек. (Как в нашем случае). Тогда основная проблема это время disk seek, не скорость передачи данных. В этом случае выгоднее иметь файл разбросаным по серверам.
Кстати очень много файлов это сколько? Порядок какой?
Спасибо!
Кстати очень много файлов это сколько? Порядок какой?
Спасибо!
У нас обычные SATA 3.5" диски, полки — потому что так дешевле в пересчёте на гигабайт места в хранилище. Обычно 1 или 2 полки на 24 диска. Памяти стараемся побольше поставить (96 гигов, например), чтобы page cache хоть сколько либо эффективно работал. В общем, ничего шикарного. Вот если бы у нас были машинки с 256 гигами и SSD дисками (привет, MongoDB), нас можно было бы обвинять в поедании чёрной икры руками :)
Кусочек из большого файла у нас можно получить без проблем, в команде write можно задать offset и size, так что тут никакой проблемы нету. Есть смысл бить файл на куски только если у вас количество активных файлов сравнимо с количеством дисков в хранилище. Сходу приходит в голову пример с образами дисков для виртуализации.
Очень много — это по-разному. В одном из сервисов сейчас порядка 50 миллиардов ключей в трёх копиях, обслуживает их суммарно 12 машин (то есть примерно по 15 миллиардов ключей и по 4 машины в каждом ДЦ). Но там записи мелкие, единицы килобайт. Нагрузка порядка 10к запросов на чтение в секунду в вечернее время.
Есть другие сервисы, там файлы намного больше, десятки мегабайт. Существенно меньше файлов, зато по объёму — почти петабайт (опять же, в трёх копиях). Планируем перешагнуть рубеж в 10 петабайт в следующем году.
Кусочек из большого файла у нас можно получить без проблем, в команде write можно задать offset и size, так что тут никакой проблемы нету. Есть смысл бить файл на куски только если у вас количество активных файлов сравнимо с количеством дисков в хранилище. Сходу приходит в голову пример с образами дисков для виртуализации.
Очень много — это по-разному. В одном из сервисов сейчас порядка 50 миллиардов ключей в трёх копиях, обслуживает их суммарно 12 машин (то есть примерно по 15 миллиардов ключей и по 4 машины в каждом ДЦ). Но там записи мелкие, единицы килобайт. Нагрузка порядка 10к запросов на чтение в секунду в вечернее время.
Есть другие сервисы, там файлы намного больше, десятки мегабайт. Существенно меньше файлов, зато по объёму — почти петабайт (опять же, в трёх копиях). Планируем перешагнуть рубеж в 10 петабайт в следующем году.
Понятно. Спасибо. У нас примерно 360 миллиардов документов сейчас. Плюс индексы к ним. Нагрузки в среднем 5-6К в секунду. Пик нагрузки по вечерам 80-100К запросов в секунду. Вот сейчас думаем как поднять пиковвую произвождительность без катастрофических расходов :)
Можете сравнить elliptics и ceph как хранилища объектов, без упора на eblob?
Почему у ceph 100500 настроек а у elliptics 2?
Как жить без сишной либы?
Чем можно отправдать отсутствие возможности просмотра списка содержимого в кластере elliptics?
Планируется ли когда-нибудь стабильная, долгоподдерживаемая версия API eblob и elliptics?
Почему у ceph 100500 настроек а у elliptics 2?
Как жить без сишной либы?
Чем можно отправдать отсутствие возможности просмотра списка содержимого в кластере elliptics?
Планируется ли когда-нибудь стабильная, долгоподдерживаемая версия API eblob и elliptics?
Можете сравнить elliptics и ceph как хранилища объектов, без упора на eblob?
Elliptics — DHT, ceph — CRUSH.
Почему у ceph 100500 настроек а у elliptics 2?
Потому что разработчики ceph по непонятной лично мне причине решили, что пусть админ думает обо всём. У нас, конечно, не 2 настройки, а пара десятков, но бОльшая часть забот о перенастройке маршрутизации при изменении конфигурации кластера делает сам Elliptics, а не админ, и, с нашей точки зрения, это очень правильно.
Как жить без сишной либы?
ЗАМЕЧАТЕЛЬНО! Нет, правда, новый API намного лучше почти во всех случаях, а уж написать поверх него сишную обёртку можно, если очень надо.
Чем можно отправдать отсутствие возможности просмотра списка содержимого в кластере elliptics?
Вам куда отправить список из 50 миллиардов ключей? Итерироваться по ключам, кстати, можно.
Планируется ли когда-нибудь стабильная, долгоподдерживаемая версия API eblob и elliptics?
Elliptics 2.24 стал стабильным летом этого года, поддерживаться будет до лета следующего года. Релиз следующей стабильной версии в планах на эту зиму, будем стараться раз в пол года релизиться.
Elliptics — DHT, ceph — CRUSH.
Почему у ceph 100500 настроек а у elliptics 2?
Потому что разработчики ceph по непонятной лично мне причине решили, что пусть админ думает обо всём. У нас, конечно, не 2 настройки, а пара десятков, но бОльшая часть забот о перенастройке маршрутизации при изменении конфигурации кластера делает сам Elliptics, а не админ, и, с нашей точки зрения, это очень правильно.
Как жить без сишной либы?
ЗАМЕЧАТЕЛЬНО! Нет, правда, новый API намного лучше почти во всех случаях, а уж написать поверх него сишную обёртку можно, если очень надо.
Чем можно отправдать отсутствие возможности просмотра списка содержимого в кластере elliptics?
Вам куда отправить список из 50 миллиардов ключей? Итерироваться по ключам, кстати, можно.
Планируется ли когда-нибудь стабильная, долгоподдерживаемая версия API eblob и elliptics?
Elliptics 2.24 стал стабильным летом этого года, поддерживаться будет до лета следующего года. Релиз следующей стабильной версии в планах на эту зиму, будем стараться раз в пол года релизиться.
Elliptics — DHT, ceph — CRUSH.
CRUSH-то получше тупого DHT будет
Потому что разработчики ceph по непонятной лично мне причине решили, что пусть админ думает обо всём. У нас, конечно, не 2 настройки, а пара десятков, но бОльшая часть забот о перенастройке маршрутизации при изменении конфигурации кластера делает сам Elliptics, а не админ, и, с нашей точки зрения, это очень правильно.
Потому что разработчики ceph хотели предоставить возможность пользователям самим решать что для них лучше, если им не нравятся настройки по умолчанию.
Elliptics же чёрный ящик с лампочками «работает/не работает» и рукояткой «включить/выключить» — все православные настройки zbr вносит напрямую в код.
ЗАМЕЧАТЕЛЬНО! Нет, правда, новый API намного лучше почти во всех случаях, а уж написать поверх него сишную обёртку можно, если очень надо.
без сишного api замечательно жить в яндексе. А на остальных вам положить.
Вам куда отправить список из 50 миллиардов ключей? Итерироваться по ключам, кстати, можно.
А у меня меньше. И я не хочу держать к elliptics ещё и индекс где-то. И не хочу ходить по нодам и всё в них «итерировать».
Тошик, это опять ответ в стиле «нам не надо, на остальных положить»
Elliptics 2.24 стал стабильным летом этого года, поддерживаться будет до лета следующего года. Релиз следующей стабильной версии в планах на эту зиму, будем стараться раз в пол года релизиться.
тут проблема в понимании сути стабильной версии: обычно в стабильную версию портируются исправления ошибок из текущей версии. У вас же стабильная версия это когда API не ломается…
А уж если меняется API… то давайте обновлять все ноды, fastcgi фронтенды, пересобирать eblob-ы…
Как вы там вообще живёте — при каждом обновлении таскаете данные из старой версии в новую?
В общем, по моему мнению, изначальная идея была отличная и наверняка вы её неплохо реализовали для внутренних нужд яндекс. Однако пользоваться elliptics без копания в коде и глубокого понимания как что работает вне яндекс-а в сколько-нибудь серьёзном проекте нереально. У вас даже публичного списка рассылки нет :(
Потому что разработчики ceph хотели предоставить возможность пользователям самим решать что для них лучше, если им не нравятся настройки по умолчанию.
Мы тоже не решаем за пользователей — все настройки, которые имеют смысл, выносятся в конфигурационный файл. Если вам известны опции, которые хотелось бы настраивать — дайте знать, а лучше — присылайте pull request :)
без сишного api замечательно жить в яндексе. А на остальных вам положить.
Опять же, если найдутся люди, которым будет нужен сишный API, то можно говорить, пока что мне о них не известно.
А у меня меньше. И я не хочу держать к elliptics ещё и индекс где-то.
В таком случае вам наверняка подойдут вторичные индексы, которые уже есть в Elliptics!
тут проблема в понимании сути стабильной версии: обычно в стабильную версию портируются исправления ошибок из текущей версии.
Как тогда вы объясните, что новая LTS версия со старой будет пересекаться по времени жизни в полгода? В течение этого времени будут backport'ироваться все исправления ошибок, а так же фичи, которые не ломают API и ABI.
У вас даже публичного списка рассылки нет :(
Давайте поговорим об этом в публичной рассылке?
честно говоря, я смотрел elliptics где-то полгода-год назад и все мои комментарии относятся к соответствующим верисиям. Я уверен что Поляков за полгода и новую ос при желании выпилит.
А ссылку на публичную рассылку, в которой за год 21 топик от 5 человек вы бы куда-нибудь на видное место на сайте воткнули…
А ссылку на публичную рассылку, в которой за год 21 топик от 5 человек вы бы куда-нибудь на видное место на сайте воткнули…
Elliptics мы выпилили по причине слишком сильной черноты ящика. Когда оно начало ломаться без причины, починить мы не смогли. Ответить и помочь на тот момент никто не смог.
Я еще помню адушку с пакетами, когда elliptics-node конфликтовал c elliptics-node-yandex, который был в зависимостях у ellipticsproxy. Некрасивые конфиги, когда в одном сервисе параметры задаются в одном стиле, в другом — по-другому. А в доках вообще все по-третьему написано.
Перешли на ceph и довольны как слоны.
— настроек из коробки не сильно много. Если не нужно ничего экзотического, деплоится одной командой. Если нужно тонко настроить — тут большой простор. CRUSH позволяет настроить все именно так, как душе угодно, вплоть до наложения на конкретную инфраструктуру.
— система многофункциональна. Хочешь, key-object, хочешь, блочное устройство или маунти вообще как файлуху.
— развивается и пилится быстрыми темпами. Недавно заработало зонирование и геокластер для key-object хранилища, например.
— интеграция со всеми популярными продуктами. opennebula, openstack, cloudstack, proxmox, KVM.
— все есть в ядре и репах, ничего не надо собирать.
— быстро и надежно. Вообще не ломается. Если ломается, то само чинится.
Как-то так.
Я еще помню адушку с пакетами, когда elliptics-node конфликтовал c elliptics-node-yandex, который был в зависимостях у ellipticsproxy. Некрасивые конфиги, когда в одном сервисе параметры задаются в одном стиле, в другом — по-другому. А в доках вообще все по-третьему написано.
Перешли на ceph и довольны как слоны.
— настроек из коробки не сильно много. Если не нужно ничего экзотического, деплоится одной командой. Если нужно тонко настроить — тут большой простор. CRUSH позволяет настроить все именно так, как душе угодно, вплоть до наложения на конкретную инфраструктуру.
— система многофункциональна. Хочешь, key-object, хочешь, блочное устройство или маунти вообще как файлуху.
— развивается и пилится быстрыми темпами. Недавно заработало зонирование и геокластер для key-object хранилища, например.
— интеграция со всеми популярными продуктами. opennebula, openstack, cloudstack, proxmox, KVM.
— все есть в ядре и репах, ничего не надо собирать.
— быстро и надежно. Вообще не ломается. Если ломается, то само чинится.
Как-то так.
Вы держите 3 копии одного ключа в каждой группе (в каждом датацентре), или во всех группах суммарно?
Если только 2 сервера из трех подтвердили запись ключа, что помешает третьему серверу ответить 404 на чтение этого же ключа в будущем?
Если только 2 сервера из трех подтвердили запись ключа, что помешает третьему серверу ответить 404 на чтение этого же ключа в будущем?
Мы держим по копии в каждой группе, суммарно 3 копии…
Даже если третий сервер вернет «no such file», то копии есть еще в 2 группах, куда клиент и сходит, чтобы достать нужный файл, при этом запустится процедура автоматического восстановления и файл зальется на сервер, где он по каким-то причинам потерялся. После этого файл будет снова в трех копиях.
Даже если третий сервер вернет «no such file», то копии есть еще в 2 группах, куда клиент и сходит, чтобы достать нужный файл, при этом запустится процедура автоматического восстановления и файл зальется на сервер, где он по каким-то причинам потерялся. После этого файл будет снова в трех копиях.
Большое спасибо автору и коментаторам за интересную статью и содержательные коменты!
Есть пара вопросов:
Первый вопрос к EuroElessar, в одном из коментариев вы написали «Мы считаем sha512 от имени файла, получаем соответствующий записи ключ», а как быть в случае, когда нужно хранить много файлов с одинаковыми именами?
Второй вопрос, вот существует приложение которое работает с Elliptics, оно обращается к кластеру по какому-то ip-адресу, который принадлежит какой-либо ноде (предполагаю), и тут нода падает и ip-адрес становится недоступным. Соответственно приложение теряет кластер из виду. Как устраняется такая ситуация? Разъясните этот момент (хотя предполагаю что запущено несоклько прокси и у «приложения» есть список адресов кластера).
Есть пара вопросов:
Первый вопрос к EuroElessar, в одном из коментариев вы написали «Мы считаем sha512 от имени файла, получаем соответствующий записи ключ», а как быть в случае, когда нужно хранить много файлов с одинаковыми именами?
Второй вопрос, вот существует приложение которое работает с Elliptics, оно обращается к кластеру по какому-то ip-адресу, который принадлежит какой-либо ноде (предполагаю), и тут нода падает и ip-адрес становится недоступным. Соответственно приложение теряет кластер из виду. Как устраняется такая ситуация? Разъясните этот момент (хотя предполагаю что запущено несоклько прокси и у «приложения» есть список адресов кластера).
а как быть в случае, когда нужно хранить много файлов с одинаковыми именами?
Для этого можно хранить их в разных namespace'ах, тогда немного по другому будет считаться hash-сумма и у них в итоге будут разные идентификаторы.
Второй вопрос, вот существует приложение которое работает с Elliptics, оно обращается к кластеру по какому-то ip-адресу, который принадлежит какой-либо ноде (предполагаю), и тут нода падает и ip-адрес становится недоступным. Соответственно приложение теряет кластер из виду. Как устраняется такая ситуация? Разъясните этот момент (хотя предполагаю что запущено несоклько прокси и у «приложения» есть список адресов кластера).
Как правило у нас запущено какое-то количество proxy-серверов, над которым стоит некоторое количество балансировщиков. В итоге приложения идут по dns-имени балансировщиков, а они уже, в свою очередь, раскидывают запросы по проксям.
EuroElessar спасибо за статью, которая не потеряла актуальность даже спустя эти годы) Сейчас мне потребовалось проанализировать алгоритм этого распределения групп Elliptics между дата-центрами. Особенно интересует проблема балансировки между разными по мощности дата-центрами. Я помню, что когда-то давно я видел картинку, которая иллюстрирует его, но не могу найти. Думаю, что это как-то было связано с Mastermind, но по нему тоже нет почти никакой документации. Вы случайно не знаете, есть что можно почитать на эту тиму?
В классическом Elliptics у каждого датацентра свое кольцо и, как следствие, своя копия данных (вроде оно называется группой, но могу ошибаться за давностью лет). Каждый hashring независимый, поэтому, теоретически, в них может быть разное количество машин, но практического смысла делать их разными по объему нет, так как все данные лежат во всех кольцах.
Mastermind это иной проприетарный способ репликации, построенный поверх Elliptics'а, @ToSHiCможет наверное рассказать про него больше.
Sign up to leave a comment.
Как устроены облака Яндекса: Elliptics