Компания
315,65
рейтинг
30 октября 2013 в 13:33

Разработка → Как устроены облака Яндекса: Elliptics

За последние несколько лет в мире IT появилась модная тенденция – использование всего «облачного» для разработки новых продуктов. Публичных облачных провайдеров не так много, самый популярных среди них – Amazon. Однако многие компании не готовы доверять приватные данные кому-либо, при этом хотят хранить их надежно, и поэтому поднимают частные небольшие облачка.

Любое облако состоит из двух основных компонентов: Единой Точки Входа (ЕТВ) и Облачной Магии (ОМ). Рассмотрим облачное хранилище Amazon S3: в роли ЕТВ используется довольно удобный REST API, а Облачную Магию обеспечивают эльфы, работающие на долларах. Компании, желающие разместить в S3 небольшие видеофайлы или базу данных, предварительно считают на калькуляторе сумму, которую они будут платить в месяц при планируемой нагрузке.

Эта статья про другое облачное хранилище, в котором эльфы питаются Духом Свободы, электричеством и еще им нужно немножечко «кокаина».

Называется это хранилище Elliptics.

История его создания берет свое начало в далеком 2007 году как части POHMELFS. В следующем году Elliptics был вынесен в отдельный проект, и в нем было перепробовано множество различных подходов к распределенному хранению данных, многие из них не подошли из-за сложности, из-за слишком малой практичности в реальной жизни. В конце концов его автор, Евгений Поляков, пришёл к созданию Elliptics в современном виде.

Отказоустойчивость


Это первая из Пяти Стихий, на сохранение которых направлен Elliptics. Машины постоянно ломаются, жесткие диски выходят из строя, а эльфы время от времени устраивают забастовки и кидаются корой. Дата-центр тоже может в любое время выпасть из нашего мира, в силу Черной Магии и Колдовства. Наиболее очевидные из них – это Обрыв Кабеля и Потеря Электричества.

Одна грустная история
Однажды, во время дождя, одному маленькому котенку стало холодно, и он решил погреться. Поблизости не оказалось ни одного помещения, кроме трансформаторной будки, которая была сделана строго по ГОСТ’у – с проемом снизу сантиметров в 10. Трансформатор закоротило, и одним котенком стало меньше, а дата-центр оказался без электричества. Случилось это в выходной, в субботу, и поэтому штатные электрики не были на рабочем месте и не могли восстановить электроснабжение. Конечно, дизель-генератор имелся и работал, но топлива хватило всего на несколько часов. Служба безопасности отказалась пускать на территорию дата-центра оперативно вызванный бензовоз. В конце концов, все решилось благополучно, но никто не застрахован от подобных ситуаций.

Все уже давно знают, что делать в случае, если отключился диск или сервер. Но никто не задумывается, что будет с их системой, если откажет дата-центр, регион Amazon'а или произойдет иное крупное событие. Elliptics же изначально планировался для решения такого класса проблем.

В Elliptics’е все документы хранятся по 512-битовым ключам, которые получаются как результат sha512-функции от названия документа. Все ключи можно представить в виде Distributed Hash Table (DHT), кольца с диапазоном значений от 0 до 2512. Кольцо случайным образом делится между всеми машинами одной группы, причем каждый ключ может одновременно храниться в нескольких различных группах. Можно приближенно считать, что одна группа – один дата-центр. Как правило, компания Яндекс хранит 3 копии всех документов, и в случае выхода из строя какой-то машины мы теряем лишь одну копию части кольца. Даже при выходе из строя всего дата-центра информация не теряется, у нас все документы остаются еще как минимум в двух копиях, и поэтому эльфы до сих пор могут нести радость людям.

Расширяемость


Эльфам-администраторам всегда хотелось иметь возможность подключать дополнительные машины, и Elliptics может это делать! При подключении нового компьютера к группе, он забирает себе случайные интервалы из тех 2512 ключей, и все последующие запросы по этим ключам будут приходить на данную машину.

Если у нас есть три группы, состоящие из сотни машин каждая, то добавление новых повлечет за собой ребалансировку и, как следствие, придется большие объемы данных переливать по сети для их восстановления. Для тех, кому это не подходит, мы разработали систему балансировки нагрузки – Mastermind, которая работает на облачной платформе Cocaine. Mastermind – это набор равноправных супер-узлов, которые определяют в каких группах будет храниться тот или иной файл исходя из нагрузки на каждый из серверов. Тут тоже есть непростая Математическая Магия – в расчет принимается свободное место, загруженность дисков, нагрузка на центральный процессор, загрузка свичей, drop rate и многое другое. В случае выхода из строя любого из узлов Mastermind все продолжает работать, как и прежде. Если размер групп поддерживается небольшим, тогда при добавлении новых машин достаточно им выдать новую группу и дать знать об этом Mastermind’у. В этом случае к идентификатору файла добавляется информация о том, в каких группах его следует искать. Этот механизм позволяет обеспечивать поистине бесконечное и очень простое расширение хранилища.

Сохранность данных


Давайте рассмотрим, что делает система со старыми данными, которые оказались не на тех машинах после балансировки или вообще потерялись.

На этот случай в Elliptics предусмотрена система восстановления. Схема ее работы выглядит следующим образом: она проходится по всем машинам и, в случае если данные лежат на не своей машине, перемещает их на нужную. Если окажется, что какой-то документ лежит не в трех копиях, то во время этой процедуры документ будет размножен на нужные машины. При этом если система работает с Mastermind’ом, то номер группы расположения файла берется из мета-информации. Скорость восстановления зависит от многих факторов и нельзя назвать точную скорость восстановления ключей, но, как показывает нагрузочное тестирование, наиболее узким местом является сетевой канал между машинами, который используется для передачи данных.

Скорость


Elliptics обладает небольшими накладными расходами и способен на одной машине при работе к кэшем выполнять до 240 тысяч операций чтения в секунду. При работе с диском скорость, естественно, падает и упирается в скорость чтения данных с диска.

На основе Elliptics реализован проект HistoryDB. С его помощью мы храним логи, поступающие от различных внешних событий. Во время тестирования, группа из трех машин спокойно и ровно справлялась с нагрузкой в 10 тысяч запросов в секунду, когда писались логи от 30 млн пользователей. При этом 10% из них генерировала 80% всех данных. В сумме на 30 млн пользователей пришлось около 500 млн обновлений каждый день. Однако просто хранить эти данные было бы слишком просто. Поэтому система была протестирована таким образом, что работая под нагрузкой, она позволила получить список всех пользователей, которые были активны в определенный период (день/месяц), посмотреть логи любого пользователя за любой день и имелась возможность добавить любые другие вторичные индексы к пользовательским данным.



Также на основе Elliptics в компании Яндекс построена работа таких сервисов как Яндекс.Музыка, Фотки, Карты, Маркет, вертикальные поиски, поиск по людям, бэкап почты. Готовится к переезду и Яндекс.Диск.

Простота архитектуры


В Elliptics’е клиенты подключаются напрямую к серверам, и это позволяет:
  • иметь простую архитектуру;
  • гарантировать, что транзакции выполняются корректно;
  • всегда знать, какая машина в группе отвечает за тот или иной ключ.

Для пользователей сервиса хранения данных существуют следующие API, с помощью которых можно легко записывать, удалять, читать и обрабатывать данные:
  • асинхронная библиотека на C++ 11
  • биндинг на Python
  • HTTP-фронтенды на основе FastCGI и TheVoid (используя boost::asio)

Однако серебряной пули не существует, и у Elliptics существуют свои ограничения и проблемы:
  • Eventual consistency. Так как Elliptics полностью распределен, то при различных неполадках сервер может отдать версию файла старее, чем актуальная. В некоторых случаях это может быть неприменимо, тогда за счет проседания времени ответа можно использовать более надежные способы запроса данных.
  • Из-за того, что данные клиентом пишутся параллельно на несколько серверов, сеть между клиентом и серверами может стать узким местом.
  • API может быть недостаточно удобен для высокоуровневых запросов. На данный момент мы не предоставляем удобных SQL-like запросов к данным.
  • Так же в Elliptics нет высокоуровневой поддержки транзакций, поэтому невозможно гарантировать, что группа команд либо выполнится вся, либо не выполнится вообще.

В следующих статьях мы приведем пример использования Elliptics и расскажем больше технических подробностей: внутреннее строение кэша, работа нашего backend’а eblob, стриминг данных, вторичные индексы и многое другое.
Автор: @EuroElessar
Яндекс
рейтинг 315,65

Комментарии (58)

  • +5
    Вопрос немного не в тему но как связаны Cocaine и Elliptics, с Яндексом и reverbrain.com/ это ваша дочерняя организация, или просто сотрудничаете, или вы их купили?
    • 0
      Как один из вариантов: бывшие разработчики организовали свою команду и продолжили проект…
      или reverbrain просто на основе открытых исходников, строят свою модификацию под Амазон.
      Сравнивать исходники Эклиптика и Кокаина — просто нет времени…
      • 0
        Сравнивать исходники Elliptics и Cocaine будет очень забавно, ведь Elliptics — это хранилище, а Cocaine — облачная платформа для приложений :)
    • +7
      Cocaine и Elliptics — это open-source, права на код написаны в заголовке каждого файлика, то есть права на эти программы принадлежат конкретным людям. Вообще, и Elliptics, и Cocaine начинались как pet-project Жени Полякова и Андрея Сибирёва соответственно, а уже потом в них (на ранней стадии, прошу заметить) увидели перспективу и начали применять внутри компании.

      А reverbrain.com — это сообщество людей, которые пишут Elliptics. Сайт создавался как площадка, на которой мы делимся знаниями с пользователями.
      • +1
        Спасибо, теперь ясно что к чему.
  • +2
    Описан riakdb, как он есть. Чем ваша система лучше?
    • +1
      Очевидно, что эти системы имеют много общего, так как обе были написаны под воздействием драфта Amazon Dynamo, опубликованного в далеком 2006 году.

      А теперь по пунктам:
      • У Riak более-менее нормальная кросс-датацентровая репликация данных есть только в платной версии
      • Насколько мне известно, в Riak странно устроена репликация данных. Все машины там пронумерованы, причем каждая, например, двойка подряд идущих машин хранит свою часть кольца. Поэтому если добавить машину «как-то не так», то произойдет почти полная перекачка всех данных внутри дата-центра. Так же это накладывает ограничение на количество добавляемых машин, их количество должно быть кратным количеству копий
      • Backend Riak'а потребляет гораздо больше памяти, чем наш eblob
      • Riak написан на Erlang, как правило, вам будет очень сложно понять что идет не так и попробовать это исправить :)


      Это то, насколько мне известно, что у Riak плохо. Но для проведения более детального сравнения нужен кто-нибудь, кто очень хорошо разбирается в Riak, тогда мы готовы побеседовать :) Так же мы готовы пострелять и сравнить обе системы в плане производительности
      • 0
        Да, всё так. Кросс-датацентровую репликацию я не пробовал, потому что и риак сам по себе не устроил. Перебиваемся couchdb пока.

        Про оптимизацию добавления машин в кольцо были сообщения, вроде как.

        Потребление памяти не знаю, не смотрел.

        Ок, а как у вас обстоят дела с решением конфликтов после split brain? Векторные часы, просто часы, как в монго ( :) ), или еще что?
        • +1
          Ок, а как у вас обстоят дела с решением конфликтов после split brain?


          Есть несколько подходов:
          • Просто часы, это подходит в большинстве случаев
          • Можно построить свои векторные часы на основе примитивов Elliptics, например, с помощью Lookup и атомарного Compare&Swap (в таком случае главную роль играет sha512 чексумма данных)
          • А можно отдавать только те данные, которые ближе :) Это корректно, когда мы точно знаем, что данные не переписываются, а отдавать их нужно как можно быстрее


          • +1
            Т.е. опционально для конкретных данных можно выбрать способ? Звучит интересно.
      • –2
        > Riak написан на Erlang, как правило, вам будет очень сложно понять что идет не так и попробовать это исправить :)

        Я бы еще сказал, что как правило это значит, что он очень медленный (в сравнении с другими). Правда, смотрел относительно давно, конечно.
        • +1
          Я не могу делать таких утверждений без проведения нагрузочного тестирования, как бы не хотелось)
      • +1
        > Насколько мне известно, в Riak странно устроена репликация данных.

        Нормально там репликация устроена. Точно не так, как у вас написано. И ограничений таких нет на количество добавляемых машин. В общем, весь пункт не соответствует действительности.

        > Riak написан на Erlang, как правило, вам будет очень сложно понять что идет не так и попробовать это исправить :)

        Для многих Erlang плюс, потому что в плюсах копаться мочи уже нет. А риак код — он маленький, как на ладони.
        • +1
          А вы умеете правильно готовить Riak? Было бы интересно сравнить: позаливать много данных, посмотреть, как ведёт себя при потере ДЦ или диска, при сбоях сети, как восстанавливается и т.д.

          Машинки и инструменты для нагрузочного тестирования у нас есть.
          • 0
            У нас 50-хостовый кластер риака стоял несколько лет. Сейчас ужали до 17-нодного. Данных — несколько сотен гигабайт, не терабайты.

            Сбоев было много (работаем поверх EC2, довольно часто вылетают хосты), восстанавливается практически всегда нормально, но однажды на два дня потеряли часть данных (пока делали восстановление InnoDB структуры), после пары лет работы (но версия была старая).

            Сейчас работаем с LevelDB-бэкендом, полёт нормальный. Кросс-датацентр-репликацию не используем.

            Также см. lionet.livejournal.com/tag/riak
            • +2
              Лев Валкин, это ты? :) Мы с тобой после Стачки в Ульяновске общались пол года назад, ты обещал eblob попробовать.

              Просто хранить записи, особенно когда они в памяти помещаются — элементарно. Когда появляются географически разнесённые ДЦ, количество записей становится большим, да и вообще к машинам подключены полки на 24-48 дисков — всё становится сложнее и интереснее. Когда же из такой конструкции начинаем пытаться выжимать максимум по производительности, то тут нужны очень хорошие знания о внутреннем устройстве системы и её конфигурации.

              Хорошим примером кажущейся простоты является MongoDB. Пока нагрузка не слишком большая и данных относительно мало — она правда работает без особых проблем.
            • 0
              Хостим нечто подобное на Cassandra, около 50 нод, больше 100 терабайт. Опыт накоплен огромный, анализ Heap дампов, кодовой базы, фиксы. Было бы интересно сравнить плюсы и минусы с Riak, обслуживающим подобную конфигурацию.
          • –1
            По поводу «правильно готовить»: это не хадуп, чтобы его долго настраивать. Риак запускается за несколько минут, особых проблем при запуске не вызывает. Так что не знаю, как я могу помочь его приготовить.
    • +4
      Riak обладает фатальным недостатком.
      • 0
        Недостаток, что он не написан в яндексе?
  • +5
    Кокаин, мулька… Яндекс знает толк в веществах.
  • +2
    Интересно, а только мне одному картинка Elliptics напомнила очертания суперкомпьютера из детской книжки «А я был в Компьютерном Городе»? :)

    image

    Сразу прошу прощения за занятое место на экране, но тег спойлер почемуто не работает…
    • +2
      Это Cray-1. Один из первых суперкомпьютеров.
      • 0
        Спасибо за информацию. А то из-за цветовой раскраски мне раньше казалось, что это плод фантазии авторов книжки.
  • +1
    Что делаете с нагрузкой на базу хешей файлов? Насколько я понимаю такая база должна быть централизованной. Какие нагрузки (запрос/сек) реально вы испытывали?
    Спасибо!
    • 0
      У нас нет никакой базы хешей файлов, поэтому никакую нагрузку на нее мы не испытываем.

      Хотя, может, я и некорректно понял ваш вопрос, не могли бы вы его пояснить?
      • 0
        Когда приходит запрос на файл как вы определяете на каком сервере он лежит?
        • 0
          Примерно так:
          • Мы считаем sha512 от имени файла, получаем соответствующий записи ключ
          • У нас всегда есть свежая таблица маршрутизации для всех групп, в ней мы храним только начала секторов, принадлежащих машине, поэтому она имеет небольшой размер и спокойно помещается в памяти
          • По таблице маршрутизации за O(1) всегда можно узнать для каждой из групп где должен лежать файл

          Поэтому ответ на этот вопрос всегда можно дать за O(1) из любого места Elliptics Network.
          • 0
            А файлы вы храните целиком на одном сервере? Это же не эффективно будет для очень маленьких и очень больших фалов.
            • 0
              Мы достаточно эффективно храним файлы размером от единиц килобайт до нескольких гигабайт. На диске данные хранятся в блобах, как правило, по несколько миллионов ключей в файле.

              С данными большего объема теоретически могут возникнуть проблемы, но тестирований еще не проводили, да и нужды не было.
              • 0
                Мне кажется логичнее было бы хранить данные кусками фиксированного размера. Большие файлы дробить, а маленькие объединять. В вашей текущей архитектуре будет вам будет тяжело рахбираться с миллиардами маленьких файлов и большими файлами в несколько террабайт. Куски фиксированного размера позволят эффективнее использовать дисковое пространство на сервере и повысят производительность (TPS) при доступе к большим файлам.
                • +3
                  У вас практические знания с цифрами?

                  Нам очень легко разбираться с файлами, мы не обращаем внимание на размер. У нас есть большое преимущество перед файловыми системами — мы заранее знаем, какой будет размер записи, и применяем наиболее эффективный метод записи — append записи в конец большого блоба. В итоге мы максимально эффективно используем дисковое пространство, оверхэд составляют только служебные заголовки. При этом мы минимизируем количество random seek, запись превращается в линейную. Мы не испытываем никаких проблем с фрагментацией, которые обязательно возникнут при попытке запихать несколько мелких записей в блок. И ещё надо где-то держать список пустых блоков.

                  Что касается чтения — если вы начинаете хранить файл кусками, вам сразу надо придумывать механизм склеивания этих кусков, какой-то мэппинг. При обращении к файлу вам надо делать +1 seek, чтобы поднять файл мэппинга, и линейное чтение превращается в уже не столь линейное. При записи придётся синхронизировать запись блока и обновление маппинга, желательно делать это атомарно с точки зрения клиента. Конечно, у такой схемы есть и плюсы: не надо проводить большую дефрагментацию блобов, можно хранить неограниченно большие файлы.

                  Для раздачи больших файлов мы научили nginx раздавать их непосредственно из блобов, и тут запись одним куском идеально подходит и сильно упрощает процесс.

                  А сейчас я расскажу немножко о магии. В Elliptics есть возможность запускать server-side скрипты непосредственно на той ноде, где лежат данные. То есть, если действительно есть большая необходимость хранить файлы кусками, то это можно сделать, написав не очень большую программу на языке, поддерживаемом Cocaine: C++, Python, Java, Javascript. Вы будете отправлять запись на ноду в этот скрипт, а он уже будет разбираться с мэппингом, записью в правильный блок (блок при этом записывается как обычная запись), склеиванием блоков при чтении.
                  • 0
                    Знаний с цифрами у меня тлоько про наш конкретный слуйчай, как он к вашему относится не очень понятно. В общем Вы все правильно написали про плюсы и минусы. Еще только про одну вещь я бы все таки подумал общая пропускная способность системы. Если доступ идет одновременно к ограниченному количеству файлов по сравнению с общим объемом хранимых данных, то получается выгоднее файлы разбивать на куски и разбрасывать их по серверам. Типа торрента чтобы получалось. Тогда получается максимально задействовать все головки дискови повысить общую пропускную способность хранилища.
                    • 0
                      Как правило при передачи больших файлов упираемся не в диск, а в сеть. Вот смотрим: один диск в состоянии читать данные со скоростью, допустим, 100 мегабайт в секунду, сеть, как правило, стоит гигабитная, то есть почти такая же.

                      Более того, на каждой машине стоит полка из нескольких десятков дисков, что уже многократно перекрывает возможности даже десятигигабитной сети.

                      Как бы мы не разносили файл на разные машины — мы все равно не сможем его отдать быстрее.

                      Так же стоит отметить, что на наших задачах файлов, как правило, очень много, поэтому поэтому к машинам обращаются более-менее равномерно.
                      • 0
                        Шикарно живете :) Диски по 100Мб/сек и полки на несколько десятков дисков на каждом сервере. Я в более общем случае рассуждал, когда диски медленные и сервера слабенькие могут быть, а производительность все равно нужна высокая. Плюс иногда бывает нужен не весь файл, а его кусочек. (Как в нашем случае). Тогда основная проблема это время disk seek, не скорость передачи данных. В этом случае выгоднее иметь файл разбросаным по серверам.
                        Кстати очень много файлов это сколько? Порядок какой?
                        Спасибо!
                        • +1
                          У нас обычные SATA 3.5" диски, полки — потому что так дешевле в пересчёте на гигабайт места в хранилище. Обычно 1 или 2 полки на 24 диска. Памяти стараемся побольше поставить (96 гигов, например), чтобы page cache хоть сколько либо эффективно работал. В общем, ничего шикарного. Вот если бы у нас были машинки с 256 гигами и SSD дисками (привет, MongoDB), нас можно было бы обвинять в поедании чёрной икры руками :)

                          Кусочек из большого файла у нас можно получить без проблем, в команде write можно задать offset и size, так что тут никакой проблемы нету. Есть смысл бить файл на куски только если у вас количество активных файлов сравнимо с количеством дисков в хранилище. Сходу приходит в голову пример с образами дисков для виртуализации.

                          Очень много — это по-разному. В одном из сервисов сейчас порядка 50 миллиардов ключей в трёх копиях, обслуживает их суммарно 12 машин (то есть примерно по 15 миллиардов ключей и по 4 машины в каждом ДЦ). Но там записи мелкие, единицы килобайт. Нагрузка порядка 10к запросов на чтение в секунду в вечернее время.

                          Есть другие сервисы, там файлы намного больше, десятки мегабайт. Существенно меньше файлов, зато по объёму — почти петабайт (опять же, в трёх копиях). Планируем перешагнуть рубеж в 10 петабайт в следующем году.
                          • 0
                            Понятно. Спасибо. У нас примерно 360 миллиардов документов сейчас. Плюс индексы к ним. Нагрузки в среднем 5-6К в секунду. Пик нагрузки по вечерам 80-100К запросов в секунду. Вот сейчас думаем как поднять пиковвую произвождительность без катастрофических расходов :)
                            • 0
                              Если вы в Москве и захотите побеседовать голосом — пишите и заходите к нам в офис. Голосом расспросить-рассказать будет быстрее, чем в комментариях.
                              • +1
                                В Москве бываю к сожалению редко и обычно совсем нет времени там. Если будете в Бостоне, то пишите с удовольствием встретимся!
                                • 0
                                  Кстати, до 4 ноября автор Elliptics — Евгений aka zbr в отпуске в NY, можете с ним пообщаться в каком-нибудь баре.
                            • 0
                              Чувствую себя ничтожеством со своим жалким миллиардом.
                              • 0
                                С момента того коммента уже к триллиону документов вплотную подобрались :)
  • 0
    Можете сравнить elliptics и ceph как хранилища объектов, без упора на eblob?

    Почему у ceph 100500 настроек а у elliptics 2?

    Как жить без сишной либы?

    Чем можно отправдать отсутствие возможности просмотра списка содержимого в кластере elliptics?

    Планируется ли когда-нибудь стабильная, долгоподдерживаемая версия API eblob и elliptics?
    • +1
      Можете сравнить elliptics и ceph как хранилища объектов, без упора на eblob?

      Elliptics — DHT, ceph — CRUSH.

      Почему у ceph 100500 настроек а у elliptics 2?

      Потому что разработчики ceph по непонятной лично мне причине решили, что пусть админ думает обо всём. У нас, конечно, не 2 настройки, а пара десятков, но бОльшая часть забот о перенастройке маршрутизации при изменении конфигурации кластера делает сам Elliptics, а не админ, и, с нашей точки зрения, это очень правильно.

      Как жить без сишной либы?

      ЗАМЕЧАТЕЛЬНО! Нет, правда, новый API намного лучше почти во всех случаях, а уж написать поверх него сишную обёртку можно, если очень надо.

      Чем можно отправдать отсутствие возможности просмотра списка содержимого в кластере elliptics?

      Вам куда отправить список из 50 миллиардов ключей? Итерироваться по ключам, кстати, можно.

      Планируется ли когда-нибудь стабильная, долгоподдерживаемая версия API eblob и elliptics?

      Elliptics 2.24 стал стабильным летом этого года, поддерживаться будет до лета следующего года. Релиз следующей стабильной версии в планах на эту зиму, будем стараться раз в пол года релизиться.
      • 0
        Elliptics — DHT, ceph — CRUSH.

        CRUSH-то получше тупого DHT будет

        Потому что разработчики ceph по непонятной лично мне причине решили, что пусть админ думает обо всём. У нас, конечно, не 2 настройки, а пара десятков, но бОльшая часть забот о перенастройке маршрутизации при изменении конфигурации кластера делает сам Elliptics, а не админ, и, с нашей точки зрения, это очень правильно.


        Потому что разработчики ceph хотели предоставить возможность пользователям самим решать что для них лучше, если им не нравятся настройки по умолчанию.
        Elliptics же чёрный ящик с лампочками «работает/не работает» и рукояткой «включить/выключить» — все православные настройки zbr вносит напрямую в код.

        ЗАМЕЧАТЕЛЬНО! Нет, правда, новый API намного лучше почти во всех случаях, а уж написать поверх него сишную обёртку можно, если очень надо.


        без сишного api замечательно жить в яндексе. А на остальных вам положить.

        Вам куда отправить список из 50 миллиардов ключей? Итерироваться по ключам, кстати, можно.

        А у меня меньше. И я не хочу держать к elliptics ещё и индекс где-то. И не хочу ходить по нодам и всё в них «итерировать».
        Тошик, это опять ответ в стиле «нам не надо, на остальных положить»

        Elliptics 2.24 стал стабильным летом этого года, поддерживаться будет до лета следующего года. Релиз следующей стабильной версии в планах на эту зиму, будем стараться раз в пол года релизиться.

        тут проблема в понимании сути стабильной версии: обычно в стабильную версию портируются исправления ошибок из текущей версии. У вас же стабильная версия это когда API не ломается…
        А уж если меняется API… то давайте обновлять все ноды, fastcgi фронтенды, пересобирать eblob-ы…
        Как вы там вообще живёте — при каждом обновлении таскаете данные из старой версии в новую?

        В общем, по моему мнению, изначальная идея была отличная и наверняка вы её неплохо реализовали для внутренних нужд яндекс. Однако пользоваться elliptics без копания в коде и глубокого понимания как что работает вне яндекс-а в сколько-нибудь серьёзном проекте нереально. У вас даже публичного списка рассылки нет :(
        • 0
          Потому что разработчики ceph хотели предоставить возможность пользователям самим решать что для них лучше, если им не нравятся настройки по умолчанию.

          Мы тоже не решаем за пользователей — все настройки, которые имеют смысл, выносятся в конфигурационный файл. Если вам известны опции, которые хотелось бы настраивать — дайте знать, а лучше — присылайте pull request :)

          без сишного api замечательно жить в яндексе. А на остальных вам положить.

          Опять же, если найдутся люди, которым будет нужен сишный API, то можно говорить, пока что мне о них не известно.

          А у меня меньше. И я не хочу держать к elliptics ещё и индекс где-то.

          В таком случае вам наверняка подойдут вторичные индексы, которые уже есть в Elliptics!

          тут проблема в понимании сути стабильной версии: обычно в стабильную версию портируются исправления ошибок из текущей версии.

          Как тогда вы объясните, что новая LTS версия со старой будет пересекаться по времени жизни в полгода? В течение этого времени будут backport'ироваться все исправления ошибок, а так же фичи, которые не ломают API и ABI.

          У вас даже публичного списка рассылки нет :(

          Давайте поговорим об этом в публичной рассылке?
          • 0
            честно говоря, я смотрел elliptics где-то полгода-год назад и все мои комментарии относятся к соответствующим верисиям. Я уверен что Поляков за полгода и новую ос при желании выпилит.

            А ссылку на публичную рассылку, в которой за год 21 топик от 5 человек вы бы куда-нибудь на видное место на сайте воткнули…
    • 0
      Elliptics мы выпилили по причине слишком сильной черноты ящика. Когда оно начало ломаться без причины, починить мы не смогли. Ответить и помочь на тот момент никто не смог.
      Я еще помню адушку с пакетами, когда elliptics-node конфликтовал c elliptics-node-yandex, который был в зависимостях у ellipticsproxy. Некрасивые конфиги, когда в одном сервисе параметры задаются в одном стиле, в другом — по-другому. А в доках вообще все по-третьему написано.

      Перешли на ceph и довольны как слоны.
      — настроек из коробки не сильно много. Если не нужно ничего экзотического, деплоится одной командой. Если нужно тонко настроить — тут большой простор. CRUSH позволяет настроить все именно так, как душе угодно, вплоть до наложения на конкретную инфраструктуру.
      — система многофункциональна. Хочешь, key-object, хочешь, блочное устройство или маунти вообще как файлуху.
      — развивается и пилится быстрыми темпами. Недавно заработало зонирование и геокластер для key-object хранилища, например.
      — интеграция со всеми популярными продуктами. opennebula, openstack, cloudstack, proxmox, KVM.
      — все есть в ядре и репах, ничего не надо собирать.
      — быстро и надежно. Вообще не ломается. Если ломается, то само чинится.

      Как-то так.
      • 0
        Вы Elliptics пробовали примерно 2 года назад, верно?
        • 0
          Да, верно. Есть смысл еще попробовать?)
          • 0
            Мы прилично шагнули вперёд, разработчиков стало больше, обкатанных решений больше. И научились готовить бесконечные по объёму хранилища, но об этом ещё будут статьи.

            А, ещё в Новосибе офис открыли, можно телемост сделать :) Ну или вы к нам в Московский офис заходите.
      • 0
        у меня mds работал очень плохо на трех нода с тройной репликацией на средней нагрузке ~ 200K файлов по 200G в сутки — все время подвисал и разваливался на 0.67. Не встречалось?
        • 0
          Ога. Честно сказать, эта часть до совершенства еще далека и они это доделывают в последнюю очередь. Глючит жестко.
          Все завсит от много чего. Что за железо, какая файлуха над ним, сколько ресурсов у мдс. Настроить можно, будет нормально. Но просят еще подождать ))
  • 0
    Вы держите 3 копии одного ключа в каждой группе (в каждом датацентре), или во всех группах суммарно?
    Если только 2 сервера из трех подтвердили запись ключа, что помешает третьему серверу ответить 404 на чтение этого же ключа в будущем?
    • 0
      Мы держим по копии в каждой группе, суммарно 3 копии…

      Даже если третий сервер вернет «no such file», то копии есть еще в 2 группах, куда клиент и сходит, чтобы достать нужный файл, при этом запустится процедура автоматического восстановления и файл зальется на сервер, где он по каким-то причинам потерялся. После этого файл будет снова в трех копиях.
      • 0
        Интересно. А есть публичные данные по производительности распределенного сетапа: три группы в разных ДЦ, клиенты чего-то пишут, читают микс из существующих/несуществующих ключей?
  • 0
    Большое спасибо автору и коментаторам за интересную статью и содержательные коменты!
    Есть пара вопросов:
    Первый вопрос к EuroElessar, в одном из коментариев вы написали «Мы считаем sha512 от имени файла, получаем соответствующий записи ключ», а как быть в случае, когда нужно хранить много файлов с одинаковыми именами?

    Второй вопрос, вот существует приложение которое работает с Elliptics, оно обращается к кластеру по какому-то ip-адресу, который принадлежит какой-либо ноде (предполагаю), и тут нода падает и ip-адрес становится недоступным. Соответственно приложение теряет кластер из виду. Как устраняется такая ситуация? Разъясните этот момент (хотя предполагаю что запущено несоклько прокси и у «приложения» есть список адресов кластера).
    • +1
      а как быть в случае, когда нужно хранить много файлов с одинаковыми именами?

      Для этого можно хранить их в разных namespace'ах, тогда немного по другому будет считаться hash-сумма и у них в итоге будут разные идентификаторы.

      Второй вопрос, вот существует приложение которое работает с Elliptics, оно обращается к кластеру по какому-то ip-адресу, который принадлежит какой-либо ноде (предполагаю), и тут нода падает и ip-адрес становится недоступным. Соответственно приложение теряет кластер из виду. Как устраняется такая ситуация? Разъясните этот момент (хотя предполагаю что запущено несоклько прокси и у «приложения» есть список адресов кластера).

      Как правило у нас запущено какое-то количество proxy-серверов, над которым стоит некоторое количество балансировщиков. В итоге приложения идут по dns-имени балансировщиков, а они уже, в свою очередь, раскидывают запросы по проксям.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка