Pull to refresh

Comments 14

Тарантул мне нравится, но до сих пор непонятен вопрос отказоусточивости. Если я работаю с Cassandra и использую CL=2, RF=3, то, при полной потере одного узла я сохраняю данные. Если данные особенно ценны, я могу использовать CL=3, RF=5.

У Тарантула, я так понимаю, асинхронная репликация между узлами. В этом случае при потере мастера ведущего узла будет потеряна и часть данных.

Если для работы с OAuth-токенами этим, видимо, можно пренебречь, то тут вроде более строгие требования? Или я чего-то не понимаю?
> У Тарантула, я так понимаю, асинхронная репликация между узлами. В этом случае при потере мастера ведущего узла будет потеряна и часть данных.

В последнем релизе добавили синхронную репликацию с ручным выбором мастера, позднее будет добавлен автоматический выбор мастера.
Судя по нашим первичным замерам пропускная способность проседает не более чем на 5%. Latency, конечно ж, возрастёт на время подтверждения от реплики
Можете тут пояснить? Исходя из описания: «Synchronous transactions are not considered committed and are not responded to a client until they are replicated onto some number of replicas».

Вроде как поток обработки (а каждый сервер Tarantool работает в один поток?) должен на каждой транзакции останавливаться и ждать окончания репликации, что не может не сказаться на RPS.
Для коммита транзакции нужно собрать кворум из N реплик и только после этого происходит коммит. Отсюда и появляется снижение производительности на ~5%.
Можно поверить в 5%, но в репликацию и 5% — трудно.

Возможно, термин «репликация» неверно отражает суть дела, и тут что-то типа «двухфазной фиксации изменений». Т.е. одновременно пишется во все реплики, а не «сначала пишем в одну, затем ждем, пока завершится процесс репликации».
В старых инсталляциях, когда до кворумной синхронной репликации было далеко, в критических инсталляциях мы пользовались т.н. семи-синхронной репликацией: транзакция завершалась только тогда, когда мы убеждались в том, что она доехала хотя-бы до одной реплики (механизм wait_lsn).
транзакция завершалась только тогда, когда мы убеждались в том, что она доехала хотя-бы до одной реплики (механизм wait_lsn).
Ответить


Чем это отличается от текущей реализации: «Synchronous transactions are not considered committed and are not responded to a client until they are replicated onto some number of replicas»?

Лучше бы вы не изменяли код вашего хранилища nfs/cifs, а то после ваших правок тераформ не работает и нам приходится уйму времени убивать на ручные внесения изменений. А ведь мы оставили у вас не один миллион рублей, за последние пол года.

API нашего сервиса по управлению файловыми хранилищами соответствует версии 2.32 «ванильного» OpenStack. И хотя комьюнити заявляет, что поддерживаются версии 2.7 и выше в провайдере тераформ для OpenStack, по нашей практике бывают сценарии, которые работает не со всеми версиями.
Очень интересная статья, все понятно и с картинками. И подход вообще классный — гораздо лучше все собирать из уже проверенных и работающих компонентов (nginx, tarantool) и писать как можно меньше кода. Чем как тот же Ceph делает — пишут все с нуля на С++.

Но очень не хватает цифр. Хотя бы сколько железа в каждом кластере тарантула, сколько шпинделей и петабайт, и сколько туда пролазит S3 Put-ов и Get-ов и с какой latency. Ну и что там за сеть конечно тоже интересно.

И еще вопрос — такой кластер существует в единственном экземпляре, бережно выпиленный напильником, или их несколько и Вы их сетапите по запросу?

И еще вопрос — кому может понадобиться миллиард файлов в одном бакете? И сколько времени он у вас листается, всмысле просто получение списка объектов в бакете? И сколько времени на нем выполняются лайфсайклы?

Простите, но еще вопрос — а кто хилинг делает (в видео упоминалось) FileDB?
Но очень не хватает цифр. Хотя бы сколько железа в каждом кластере тарантула, сколько шпинделей и петабайт, и сколько туда пролазит S3 Put-ов и Get-ов и с какой latency. Ну и что там за сеть конечно тоже интересно.

Поскольку категорий много, обозначу основные:


  • Фронт. 10-20Gbps сеть, ±xeon 2660v4, ±128 RAM RAM. 20-22 шт.
  • Центральная мета. 3шт. xeon 6230, 512RAM
  • Шардированное хранилище. 32 шт. xeon 6230, 512RAM
  • FileDB. 32 шт. 2660v4, 512RAM
  • Storage. Сеть 10Gbps. 1500+. от 24 x 6Tb до 36 x 14Tb. Нарезано на ~ 200к двухтерабайтных volume. Совокупная полезная ёмкость больше 150Pb.

Охарактеризовать штуками нагрузку на S3 сложно: она зависит от сценария. Т.е. "жирных" путов пролезет одно число, "мелких" — другое. Причём, что интересно, пропускная способность упирается у нас во фронты и в расчёт MD5+SHA1+SHA256.


Гарантированная обслуживаемая проверенная нагрузка — от 30к RPS и 50Gbps


И еще вопрос — такой кластер существует в единственном экземпляре, бережно выпиленный напильником, или их несколько и Вы их сетапите по запросу?

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


И еще вопрос — кому может понадобиться миллиард файлов в одном бакете?

Сорри, это не могу сказать.


И сколько времени он у вас листается, всмысле просто получение списка объектов в бакете? И сколько времени на нем выполняются лайфсайклы?

Время листинга: 1e9 / 1000 (кол-во объектов в одном листинге) / 300 (кол-во листингов в секунду) = 3333 сек ≈ 1 час.


Лайфсайклы работают "мгновенно", у нас архитектура функций жизненного цикла отличается от амазоновской. Каждый объект имеет timestamp применения lifeCycle и обработка объекта происходит в этот момент.


Простите, но еще вопрос — а кто хилинг делает (в видео упоминалось) FileDB?

Тему хилинга можно рассматривать отдельно, но в целом это демоны, работающие на стораджах, выполняющие проверку целостности и рекавери в случае необходимости и сверяющиеся с filedb.

Only those users with full accounts are able to leave comments. Log in, please.