Найбільша PHP конференція України, 1 червня: хто буде і чому варто відвідати?
×Закрыть

In-memory SQL база данных для k8s

Приветствую.

Вопрос скорее знатокам k8s и прикручивании БД к ним.
Есть задачка. Довольно древний софт, который с БД умеет работать либо через unixODBC, либо через native MySQL драйвер, либо с redis, но только как с одной нодой, про master-slave/sentinel не знает ничего.
И хочется этот софт запихнуть в k8s, в формате replicaset, т.е. чтобы можно было легко расширяться горизонтально.
Чтобы шарить состояния между нодами (контейнерами в поде в данном случае) есть мысль использовать в соседнем контейнере какую-то in-memory базу данных, но хитрость в том, чтобы они шарили данные между собой. Т.е. при поднятии нового пода через replicaset, новый под мог подтянуть состояние из текущих, плюс, данные должны быть синхронизироваться по мере поступления новых данных.
Что интересно, сохранение данных при выключении всех подов не требуется, поэтому сохранение состояния на диск не обязательно (точнее, даже не требуется, данные не долгоживущие)
Вариант с внешним Redis-хранилищем через ha-proxy возможен, но тут упираюсь в тот момент, что количество деплойментов (каждый в своем namespace) потенциально велико и количество «баз данных» в redis может не хватить.
Вариант в внешним MySQL — есть сейчас, но хочется чего-то другого, без сохранения данных на диск, а в варианте отказоустойчикого кластера только так и можно.
Чтобы понимать количество данных, в пики нагрузок не будет превышать 500МБ/namespace, время жизни от 1 сек до 6 часов. По факту это сессии.
Собственно, ищется какая-то простая in-memory БД с SQL(MySQL/UnixODBC) интерфейсом с возможностью легкого горизонтального масштабирования.

В общем, желаю пинка в нужном направлении гугления/чтения/велосипедостроения.
PS: Посмотрел на VoltDB, он не умеет unixODBC (вроде как).
PPS: Вопрос горизонтального масштабирования старого софта решен на сетевом уровне через anycast IP.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

А сколько данных? Если до гигабайта, то можно через ETCD/Zookeeper/Cosnul шарить.

Тут вопрос в том, что софт, который будет писать в базу, довольно древний и умеет работать только с тем, что умеет.
А писать драйвер для новой БД — затратное занятие.

Главный вопрос сколько инстансов таких баз данных надо поднимать? Ведь чем больше их будет, тем больше нагрузки на кластер. По описанию в голову приходит сразу Raft (raft.github.io) возможно есть какой то sql сервер на нем, или его можно написать github.com/src-d/go-mysql-server + github.com/hashicorp/raft. Но рекомендуемый размер кластера в 5 нод, там не просто так. То есть в идеале это должен быть кластер с data нодами + клиентские контейнеры в подах. (так делают с consul). В общем я бы конечно вам советовал представить свою inmemory-db как сервис, поставить ее за kubernetes-service. И уже вопрос HighAvailability решать в контексте DB сервиса.

пс: еще есть такое: github.com/vitessio/vitess
ппс: github.com/rqlite/rqlite (как вариант запилить к нему прослойку через go-mysql-server :D)

Я пока тоже склоняюсь к варианту внешнего сервиса за пределами k8s.
Количество нод.... 2-10. Нагрузка покажет.

Ну сервис может быть и на том же кластере, или на соседнем kubernetes кластере) Или вы можетепросто задеплоиться на AWS в их kubernetes и использовать их редис (запилив к примеру к нему прослойку на вон том гоу велосипеде). У нас опыт показал что дешевле и надежней купить все готовое.

AWS пока думается как резерв. Просто своего железа уже в 3 датацентрах хватает.

Может, обратить внимание на MemSQL — en.wikipedia.org/wiki/MemSQL ?

Как вариант — запустить MySQL и примаунтить in-memory disk — tmpfs volume — github.com/...​s/kubernetes/issues/28273
на самом деле вы не описали проблему которую надо решить, может есть решения получше и попроще

Задача — размазанное хранилище, которое можно запускать как часть пода.

in-memory базу данных, но хитрость в том, чтобы они шарили данные между собой.

Для подобной задачи использую Redis c включенным persistent storage. Общение с Redis идет соответствено через LoadBalancer.

очется чего-то другого, без сохранения данных на диск

еще можно посмотреть на SQL Server 2018 Express edition- работает в докере, поддерживает in-memory tables, запускается под linux.

Redis — это хорошо, но не хотелось бы иметь 1 точку отказа. Ну и да, в вашем варианте Redis — внешняя БД по отношению к подам, а хотелось бы что-то внутреннего, просто чтобы не было сложностей с разделением сервисов на центральном уровне.
SQL Server гляну, спасибо

Ну и да, в вашем варианте Redis — внешняя БД

В моё случае Redis — часть k8s кластера. Я использую кастомную сборку редис докер иммидж. Redis настроен подниматься с prepopulated data. Все данные пишутся на диск в поде. Если редис под падает- новый поднимается с со всеми данными в памяти- т.к. шарит диск на уровне k8s. Pod подключен

persistent storage

средствами k8s. Всё это дело пробрасывается на netfs чтобы шарить диск между нодами кластера.
Единственный drawback такого конфигурирования- нужен очень толстый сетевой канал между нода k8s- иначе начнутся затыки при постоянной записи Redis data

А как синхронизируете? И что происходит при падении одного из подов с редисом?

что происходит при падении одного из подов

гуглить k8s persistent volume nfs
новый под на новой ноде поднимается с подлюченым persistent volume ( ну или как настроишь)

в самом редисе надо настроить вот это:
redis.io/topics/persistence
На практике- редис у меня еще ни разу не падал- этот если только пойти ручками под прибить- поднимается новый.
Т.к. разбирался в этом всём один- то потратил на это почти полгода пока всё настроил =)

statefulsets c redis master-master replication

Я наверное, не дочитал до конца про redis, но master-master без шардинга вроде как невозможен. Т.е. если один из подов умирает, то теряется часть данных.

Подписаться на комментарии