Comments 14
У Тарантула, я так понимаю, асинхронная репликация между узлами. В этом случае при потере
Если для работы с OAuth-токенами этим, видимо, можно пренебречь, то тут вроде более строгие требования? Или я чего-то не понимаю?
В последнем релизе добавили синхронную репликацию с ручным выбором мастера, позднее будет добавлен автоматический выбор мастера.
Вроде как поток обработки (а каждый сервер Tarantool работает в один поток?) должен на каждой транзакции останавливаться и ждать окончания репликации, что не может не сказаться на RPS.
транзакция завершалась только тогда, когда мы убеждались в том, что она доехала хотя-бы до одной реплики (механизм 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, а то после ваших правок тераформ не работает и нам приходится уйму времени убивать на ручные внесения изменений. А ведь мы оставили у вас не один миллион рублей, за последние пол года.
Но очень не хватает цифр. Хотя бы сколько железа в каждом кластере тарантула, сколько шпинделей и петабайт, и сколько туда пролазит 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.
Архитектура S3: 3 года эволюции Mail.ru Cloud Storage