Information

Founded
Location
Россия
Website
www.itsumma.ru
Employees
101–200 employees
Registered
Pull to refresh
Comments 69
А с каких это пор, BD нельзя «кластеризовать» без использования docker/k8s? Даже, банальная, мастер — слейв репликация, с каким-то видом фейловера, дает уже минимальный HA для базы данных, с минимальным временем простоя.
Как по мне, проблемы баз данных в docker/k8s — лежат в другой плоскости.
Кто же говорит, что нельзя?:) Конечно можно. Тут обзор плюсов и минусов выживания именно в мире контейнеризированных систем, которые всё больше и больше начинают захватывать инфраструктурное пространство вокруг нас.
Чувствуете подвох? Мы используем k8s или Swarm для того, чтобы распределить нагрузку и избежать падения основного веб-сервера, но мы не делаем этого для БД.


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

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

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

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

Да, и это другие плоскости рассмотрены ниже:)
Никто не мешает. Вполне возможно, они именно так уже и делают. Но раз уж решили завести централизованное управление всем своим проектом, в самой своей основе предполагающее механизмы распределения нагрузки, фейловеров и пр, то логично что было бы удобнее через одну точно и управлять всем хозяйством разом? Чтобы можно было строить сценарии с зависимостями от нагрузок подсистем друг на друга, в рамках одной системы вести мониторинг, обмениваться данными и пр пр.


Когда у вас в руках молоток, все вокруг видится гвоздями.

Да, и это другие плоскости рассмотрены ниже:)


Как раз нет, точнее — очень вскольз затронуто.
Когда у вас в руках молоток, все вокруг видится гвоздями.

Или «если у вас есть джип, возможно, картошку с дачи можно возить прямо в нём и не обязательно заводить отдельно трактор»:)
Чувствуете подвох? Мы используем k8s или Swarm для того, чтобы распределить нагрузку и избежать падения основного веб-сервера, но мы не делаем этого для БД.

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


Там акцент другой:

«Всем хороша кластеризация в Kubernetes, кроме случая использования её с СУБД.»
Речь о кластеризации именно что с Kubernetes, а не любой кластеризации вообще.

Единообразия ради хотелось бы в Kubernetes, но не желательно в общем случае.

Только с мелкими базами данных и возможно. С чем серьезным — ни-ни.

А кластеризация другими средствами — это вообще о другом. Только слово «кластеризация» то же само для обозначения используется — но не более.

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

Да мускул на гигабайт дб под вордпрес будет прекрасно себе жить в k8s.
Вы мне лучше скажите, какая разница на сколько терабайт база, если для кубика важен только процесс в контейнере. А в остальном просто советую приглядется к реадинес чекам и самописным шедулерам, всё прекрасно себе настраивается с минимальными трудозатратами. Зато у вас всё будет в одном неймспейсе, не надо будет роутить трафик и все метрики будут в одном месте.
Я вам пример кассандры не просто так привел. Но, судя по ответу, у вас с ней опыта или мало, или вообще нет.

То что решается при «классическом» методе инталции кассандры через пару команд nodetool и дождаться окончания, перед началом других действий, в том же k8s тянет за собой написание обвязки дополнительной, в которой могут и будут баги и т.п.
Ну и про размер, ребаланс на 1 гигабайте данных и пол петабайта — это разное время, которое, вы, заранее знать не можете, потому сразу вопрос, какой таймаут для грейс шутдаун пода вы будите выставлять? Так что, в случаи той же касандры, просто вывести члена кассанда кластера чуть более сложнее чем, kubectl delete pod.
И тут еще не затрагивался вопрос гео-распределенного кластера.
Вы, похоже, зациклены на своей реализации кассандры и не до конца понимаете суть работы кубика. Какой вы, кстати, выставляете «таймаут для грейсшатдауна» когда у вас сервер вырубается? И при чём тут гео-распределение кластера не совсем понятно.
Я привел всего лишь один из кейсов. Баз данных на проекте много разных.
Как раз, как работает шедулер кубера мы разбирали и очень основательно.
Так что, профит от унифицированой среды, во многих кейсах, стремиться к нулю.
Какой вы, кстати, выставляете «таймаут для грейсшатдауна» когда у вас сервер вырубается?

Я не просто так выше писал про штатную ситуацию, если надо вывести члена кластера.
Отработка фейловера — это отдельная тема.
Пока понял только одно, что Вы всё пишете не просто так. Чего не могу понять, так это того, почему Вы не можете запускать весь свой стек команд в контейнере и выводить члена теми же методами, что и на железяке. В лайфсайкл пода добавьте preStop и он вам запустит всё, что нужно. При этом через рединес чек давая сервису понять, что под недоступен. Можно даже поднимать отдельный дежурный под задача которого будет сводится исключительно к грейсфул-шатдауну нужного члена. Тут всё решаемо средствами доступными из коробки.
Вот как раз
тут всё решаемо средствами доступными из коробки.
опасное заблуждение, на которое, мы так же нарвались. Все же эксплуатация больших, распределенных дб — очень сложный процесс сам по себе. С кучей подводных камней и неявных моментов. А унификация, которую все так хотят, только, привнесла дополнительный слой проблем, которые тоже пришлось решать. И профита, для бизнеса, в первую очередь, не принесло никакого.

Потому что чтобы в куб засунуть БД, надо, чтобы она изначально была спроектирована под этот оркестратор. Популярных БД таковых нет. А в остальном ситуация с засовыванием легаси баз в куб выглядит как попытка катить квадратное и носить круглое. Но! Если рассмотреть куб немного с другой плоскости — а именно как просто плоский пул ресурсов распиленных на ноды и вы гарантируете, что эти годы достаточно отказоустойчивы, то можно с ворохом обвязок запускать БД на выделенных нодах и они будут себя прекрасно чувствовать. Другой вопрос, что это куб ради куба получается.
Насчет того насколько сложно допилить условный постгрес до готового к Кубу состояния — посмотрите, напр., на проект stolon. Был один сервер бд (как приложение) — стало 100500 компонентов. И никто не гарантирует, что в них нет багов и не поясняет границы работоспособности этого карточного домика

Да ну что Вы рассказываете. Какие-то страшилки для шефов. Во всём процессе интеграции БД в кубик нужно понимать 2 простых правила: 1. БД это всё-таки стейтфул приложение 2. Виртуальные/Распределённые файловые системы это не для БД. Всё.

Ну, и приходим к тому, что нужны
а) локальные диски (они быстрые или по крайней мере могут быть такими)
б) изначально распределенные БД на уровне дизайна (kuber-native) — популярных ПОКА НЕТ. И на самом деле еще вопрос нужны ли они.

Тут и не поспоришь. Единственый момент, кубик он не для того, чтобы заботится о распределённости приложения, он для того, чтобы запускать контейнеры в зависимости от предопределёных правил (из коробки — метрик) на предоставленых ресурсах. Как будет себя вести проложение в контейнере ему, по большому счёту, по барабану. Поэтому говорить о БД как kube-native, на мой взгляд не совсем корректно.

Я согласен, что если упрощать, то да, кубернетес — всего лишь менеджер вычислительных ресурсов (как YARN, например, как Mesos или любой другой). И в этом контексте действительно без разницы — запускать базу в контейнере (т.е. по факту ц-группе) или нативно. С другой стороны, любая абстракция приносит с собой дополнительную сложность. О чем выше я и пишу. Те же базы ОЧЕНЬ не любят, когда кроме них на хосте что-то есть. И это от проблемы "шумных" соседей (когда iops, например, начинают пропадать из-за того, что кто-то рядом запустил ресурсоемкое приложение), и кончая тем, что тем же монгам и кликхаусам нужно вручную задавать кол-во аллоцированных ресурсов (до сих пор не во всем софте пофиксили правильное определение доступных ресурсов — процы, память и пр.; про опыт с Монгой могу рассказать, если интересно). Но последнее — это не только кубернетес-специфично, это вообще, если нужно шарить хост между несколькими задачами.
Вторая большая проблематика заключается в том, что кубернетес — это про запуск чего-либо на дешевом дерьмовенком железе, либо в облаке, желательно на спотовых инстансах, чтоб подешевле было. Т.е. любая вычислительная нагрузка будет убита в любой момент времени. База же — это сервис, который должен работать постоянно. МОЖНО собрать отказоустойчивый сервис БД в таких условиях, но опять же это требует больше действия, чем просто развернуть на каком-либо дедике какой-либо мускуль.
Поэтому движение в светлое будущее с правильным софтом должно быть с обеих сторон.

Во первых, конечно, интересно. Хоть и не видел еще задач которые Монго решала. Но на чужом опыте научиться было бы полезно, мне кажется. Ну а на счёт дерьмового железа это не совсем и не всегда. У нас так получилось, что в ДЦ стоят лошадиные машины под основной проект которые 80% времени используются на 20% мощности. А все остальные проекты жмуться на непонятно чём. Вот мы взяли и объединили всё в один пул ресурсов и всем зажилось хорошо. Потом оказалось, что стейджи ночью не нужны, зато аналитике которая ночью бегает хочется больше ресурсов. Так мы укладываем стейджи ночью спать вместе с их базами, а для аналитики поднимаем новые слейвы которые они своими запросами мучают до утра. Хотя, что я говорю, не мы, кубик, один раз настроили, сам всё делает.
Ну а на счёт дерьмового железа это не совсем и не всегда

У каждого свои критерии. Но давайте возьмем какой-нибудь Хадуп. Цель его разработки была именно обеспечить возможность массовой параллельной обработки данных на low-end железе, т.к. high-end избыточно дорог и вертикально долго не отмасштабируешься. Ну, и понятно, что low-end железо имеет более облегченные параметры надежности. Короче — диски будут вылетать постоянно. Возможно и что-то еще. Поэтому система сразу проектировалась с прицелом на то, что ноды могут умирать. А как только это было сделано — условно стало возможно собирать хоть из б/у вторсырья (опять же есть другие критерии — например, iops, которые ограничивают предел, целостность данных и т.п.).


У нас так получилось, что в ДЦ стоят лошадиные машины под основной проект которые 80% времени используются на 20% мощности

Т.е. опять кейс — более полная утилизация баре-метала? Может стоило на ВМ мигрировать?

Но давайте возьмем какой-нибудь Хадуп.
Мы сейчас вообще не в те дебри полезли. Давайте я вам сейчас еще одну байку расскажу про железо и не совсем железо. Случилось так, что в нашей конторе маркетологи не расчитали своих сил и рекламная компания прошла уж очень успешно, на столько успешно, что вместо планировшихся 20к пришло 150к пользователей. Система держалась как могла, но графики стали упираться в потолок. Тупо не хватало ресурсов. Большие боссы сказали: всё равно сколько будет стоить, проект должен быть онлайн, покупайте любое железо. Мы по дёрнули провайдера на предмет быстро доставить в стойки серверов, сказали — зайдите через недельку. А нагрузка растёт. Тогда пошли в амазоновское облако наподнимали ec2, добавили их в кубик и скинули туда все второстепенные сервисы. Проект скрипел, иногда подтупливал, но остался онлайн. Заняло это всё меньше часа и то из-за того, что ждали пока бд зальются. От опаратора потребовалось только раставить метки на новые инстансы, ну и дёрнуть нужные поды. Как только пик спал, инстансы убрали и всё вернулось в дц. Смогли бы мы так же расширится используюя стандартные методы, скорее всего да, но не такой малой кровью и пожалуй процент ошибок был бы больше. Всё-таки человеческий фактор, а слишком много того, что кубик делает автоматом пришлось бы делать руками.

Может стоило на ВМ мигрировать?
Надеюсь, Вы шутите.
Мы по дёрнули провайдера на предмет быстро доставить в стойки серверов, сказали — зайдите через недельку.

Типичная история. Поэтому будущее не за какой-то определенной технологией (ТОЛЬКО баре-метал, ТОЛЬКО облако и пр.), а за их синергией и правильным применением наиболее подходящей комбинации в текущей ситуации.


Надеюсь, Вы шутите.

Ценность куба, в случае, если можно делать проект на автоскейлинг группах в том же амазоне? И то — эластично, и то — эластично.

Во первых, конечно, интересно. Хоть и не видел еще задач которые Монго решала.

Условный тестовый стенд. Мощный сервер 32 ядра, 256 ГиБ ОЗУ. Нужно развернуть монга с 1ТБ данными. КХ для аналитики. И кучу мелких сервисов. На всякий случай поясню, что при прочих равных лучше было бы разделить сервисы по отдельным серверам. Дефолтный конфиг — нет памяти. Выясняем, что монга кушает чуть больше, чем дофига. По факту — "горячих" данных столько нет. Решаем, что самые умные и выставляет лимиты монге через systemd unit. Скажем, 20ГиБ. Монга начинает регулярно рестартовать. По ходу в приложеньках исправляем ситуацию, что теряется коннект (а то! в продакшене может случиться что угодно!) и чтоб они рестартовали запросы в случае ошибки. Окей. Читаем внимательно доку на Монгу. Оказывается! Что если памяти много, то она аллоцирует 50% от памяти хоста под свои нужды. Решилось банально указанием в командной строке сколько же памяти есть у монги.


Далее. Проблемы с це-группами вообще типичны.


  1. nginx пофиг на ограничение по cpu: https://github.com/kubernetes/ingress-nginx/issues/2948
  2. в java впилили буквально недавно: https://blogs.oracle.com/java-platform-group/java-se-support-for-docker-cpu-and-memory-limits
Во всём процессе интеграции БД в кубик нужно понимать 2 простых правила: 1. БД это всё-таки стейтфул приложение 2. Виртуальные/Распределённые файловые системы это не для БД. Всё.


Вполне возможно решить:

Elastic-то живет в кластере (в своем). И хорошо живет. И ребалансируясь самостоятельно и пр. задачи выполняя — какие Kubernetes решает.

И сделано у Elastic без виртуальных/распределенных файловых систем.

Посему мне просто удивительно — как еще нет СУБД полноценной под Kubernetes спроектированной.
Посему мне просто удивительно — как еще нет СУБД полноценной под Kubernetes спроектированной.

мне тоже внезапно (о чем я выше и удивляюсь). Видимо, не надо!?

Почему не сделали — потому что задача репликации и шардирования реляционной СУБД с поддержкой полноценных транзакций раз в несколько посложнее всей реализации Кубиков, а как сделать ее красиво и дешево с разбросом по N нодам, пока никто не придумал. Да, есть мультимастер репликация, но до желаемой легкости и производительности там еще очень далеко, оттого RAC все еще на коне.

Не прекрасно и не с минимальными.


Миграция бд по подам то ещё извращение.
А уж про производительность этого решения лучше как о покойниках...

И прекрсно и с минимальными. А чтобы производительность не страдала надо всегда помнимть о том как контейнеры работают. Ну и то, что контейнер это не VM, разумеется.
В итоге прибиваем гвоздями контейнеры с БД (а с ними и поды) к конкретной ноде.
Что убивает практически весь смысл в кубике. Ибо для таких подов нет скейлинга, миграций и т.п.

Спрашивается — какой в этом смысл?

Кубик ради кубика (унификация среды). Ценой резко возросшей стоимости владения этим всем.

Отойдём от определения стейтфул приложения и так, навскидку, парочку примеров. Первое это, конечно, перенести бд в неймспейс основного приложения, чтобы не гонять пакеты по сетям. Второе, ну кто вам сказал, что такие вещи не скалируются, скалируются за милую душу, только не так легко как стейтлессы, чуть больше магии. Пример который прям под рукой, с мускулом: Нужен мне еще один слейв я его репликой поднимаю, инит контейнер подтягивает бекап меняет позиции в бинлоге, находит мастер и отдаёт управление основному контейнеру который уже на всё готовое запускает мускул. Да, это всё потребует, по-хорошему, целый нод, но мне всё-равно пришлось бы его использовать. Ну и конечно вся прелесть от абстракций кубика в виде сервисов, конфигмапов и секретов. А самое прекрасное в том, что всё описаное может проделать девочка-оператор. Не нужно дёргать админа.
Первое это, конечно, перенести бд в неймспейс основного приложения, чтобы не гонять пакеты по сетям

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


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

Если условная база — 500 МБ, 1 ГБ, 10 ГБ — да, это работает. Но если условная база на 1 ТБ, то это не работает чуть более, чем совсем.


Ну и конечно вся прелесть от абстракций кубика в виде сервисов, конфигмапов и секретов.

Учитывая, что надо с ними со всеми уметь работать. Дополнительная нагрузка на оператора. А если уж это ломается… То нужно уметь добираться до самого нижнего слоя абстракции, чтобы найти корневую причину проблемы. Нет, можно, конечно, решать все проблемы пересозданием виртуальных машин и контейнеров, обвешивать все хелсчеками и молиться, что все будет ОК… Но это не инженерный подход.

Нет. То что БД в том же неймспейсе, что и основной приклад совершенно не означает, что БД и приклад попадут на один хост.
И всё-таки да. Бд точно не попадёт на тот же хост, мы же уже обсуждали. Но находясь в той же субсети пакеты будут идти по 2-му уровню (благо есть cni которые работают на 2-м), а не по 3-му как в случае перекидывания в другую подсеть.
Если условная база — 500 МБ, 1 ГБ, 10 ГБ — да, это работает. Но если условная база на 1 ТБ, то это не работает чуть более, чем совсем.
В моём примере база 850 Гигов.
Учитывая, что надо с ними со всеми уметь работать.
В том-то и дело, что не надо. Вот как раз с тем, что я привёл ничего делать не надо. Если эти абстракции не работают, то у вас проблемы другого уровня.
Но это не инженерный подход.
Видимо, у нас разные понятия об инженерных подходах. Мне он видится в упрощении управления сложными системами.

чуть больше магии

давайте без сказок

В условиях утилизации кластера хотя бы на 30-50%
БД размером от пары сотен ГБ скалируется практически никак. Просто потому что не на каждую ноду помещается.
А еще нужно пробросить БД на железо (или в крайнем случае до уровня виртуалки). Потому что если вы этого не сделаете, то производительность у вас будет просто никакая.
О чём Вы, уважаемый. Если у вас нет нодов на которые не влезает еще одна копия базы, так они у Вас и без кубика не появится. Еще раз напомню, БД это не стейтлесс, к ней нужно относится с пониманием. Мне приходилось видеть… чудаков которые базу запихивали в контейнер, ну, пытались. Но это не наш метод. Отдайте под базу целую ноду с проброской на железный диск, настройте тайнты чтобы никто туда больше не лез и вот вам полноценная инстанция бд, от обычного сервера не отличишь. Только если вам вдруг захочется её для чего-то другого попользовать — пара команд и она уже почищена и работает как нода для подов. Еще пара команд и она опять бд. В этом суть.
Повторюсь. Зачем мне вообще кубик в этом случае, если мне нужна полноценная БД. Он мне не помогает ее скалировать, а лишь затрудняет и увеличивает необходимый набор конфигураций.
Тогда и я повторюсь. Вы можете скалировать-перескалировать. Только скалирование это со стороны кубика будет ограничиваться в выделении необходимых ресурсов и запуска образа. Всё остальное должно происходить с учётом того, что бд — стейтфулл приложение.

gto сколько по Вашим ощущениям (вычислительно — процы, память, диск) — оверхед от наличия демонов кубернетеса на воркер ноде?

Да ну, о чём вы говорите! Если Вас волнует оверхед от демонов кубика, то у Вас проблемы другого уровня.
Т.е. вы только что подтвердили, что кубик в данном случае не нужен, поскольку менеджить ноды, где поместится ваша БД, вам придется ручками

Ок. Так и запишем

Вы читаете одно, понимаете другое и подтягиваете под третье. Руками делать ничего не надо, все инструменты есть в кубике из коробки. Руками нужно настроить один раз с учётом того, что скалироваться будет стейтфул приложение. Опять же пример из жизни: чтобы увеличить количесто доступных слейвов мускула дёргается кубик, который находит подходящие по ресурсам/конфигам ноды и запускает там стейтфулсет (на этом роль кубика заканчивается), далее инит контейнер подтягивает бакап, проставляет позиции по бинлогам и запускает основной контейнер. А дальше реадинес чек дожидается пока слейв догонит мастер и готово дело. Со стороны оператора это пара команд (если без проверок, то одна) и это единственная ручная работа. При желании и её можно заменить автоматикой. Вот это лучше запишите.

автоматизировать можно и поверх ВМ (например, амазон)… Смысл куб тащить?
Лишняя точка отказа.
Ога, я понимаю, это видимо особенности российского бизнеса, который тащит баре метал, поверх которого все равно нужно что-то разворачивать.
В чем я соглашусь — без куба все равно нужно делать систему оркестрации. И тут еще вопрос получится ли лучше — через куб с понятными манифестами или втаскивать какой-нибудь паппет с самописными ролями.

А дальше реадинес чек дожидается пока слейв догонит мастер и готово дело.


Внезапно это может произойти примерно никогда.

Попытки дискуссии я прекращаю, потому что с нагруженными БД нормальных размеров в k8s вы похоже опыта работы не имели вовсе.
Мне кажется Вы стали заложником определёных архитектурных решений. Это мешает Вам смотреть чуть шире и выходить за рамки. Мне тоже, честно говоря, жалко времени на то, чтобы переубеждать человека который считает невозможным то, что у меня испытано, подтверждено и успешно работает в продакшене.
менеджментить кластер той же касандры в кубере
Безумству храбрых поём мы песню!
Согласен. Тоже смутил знак равенства между отказоустойчивым кластером и «бд в контейнере». Аргументы «темной стороны» в итоге совершенно не актуальны. Да и вообще информативность стати, мягко говоря, страдает. Ни расчетов, ни алгоритмов, ни даже опыта использования.
Да и вообще информативность стати, мягко говоря, страдает. Ни расчетов, ни алгоритмов, ни даже опыта использования.

О, у нас и не было цели разжевать всё до набора готовых инструкций. Это скорее именно приглашение к диалогу, т.к. тема очень молодая и пока что вокруг неё нет устоявшихся мнений и однозначных практик. Где-то получаются неожиданные преимущества и удобства, где-то же эти удобства вдруг перечёркиваются какими-то детскими болезнями.

Как видите по не очень равному количеству пунктов за каждую из сторон, наш опыт пока склоняется в большей степени к классическим подходам в хранении данных. Но всегда интересно послушать окружающих, какие у них были истории успеха:)
Я не просил мне мануал написать. Просто давайте по-честному: Что я узнал из этой статьи? Если это «приглашение к диалогу», то это странный формат. Вон Флант (как бы я не относился к этой конторе) для диалога завел телеграм-канал. А Вы чего ждете, диалога в комментариях? Что мы Вам принесем замеры и бенчи сюда? Я думал это работает немного по-другому
А Вы чего ждете, диалога в комментариях? Что мы Вам принесем замеры и бенчи сюда? Я думал это работает немного по-другому

А почему, собственно, нет? Если вам есть, что рассказать из своего опыта — пожалуйста, делитесь, многим наверняка будет интересно. Если нет, то можете просто почитать соседей по комментариям, я уверен, они много интересного смогут рассказать из своей практики.
последнее время остановился на следующей схеме:
7 микросервисов, 14 контейнеров (7 — приложение, 7 — база данных), все это живет на vps с 2Gb озу, обычно 900мб доступно (почему такой впс — неспрашивайте).
причем, мускл-репликация, 1 контейнер бд — мастер, остальные 6 — слейвы (такая архитектура приложения).
БД в докере ради полной изоляции микросервисов, вдуг один отвалится — основная система будет работоспособной… кроме того любой контейнер БД без проблем выноситься на другой серв, в облако, етс.

Опыт показывает, с k8s есть смысл морочиться в случаее сотнях-тысяч rps (смотря какое приложение, на чем написано и т.п.), так и не удалось увидеть хороший вариант управления k8s для бд (обычно космические надсткойки с хитрыми скриптами, чекерами и т.п.), потому зачем яму копать, если с десятком-сотней контейнеров можно справиться одним баш-скриптом… вот и все окрестрация.

Я так предполагаю, что для кубернетеса поды — не долгоживущие сущности, которые могут быть отстрелены в любой момент времени. Соответственно, чтобы база как сервис выжила — она должна быть запущена в нескольких репликах. Но далее возникают дополнительные вопросы: как переключить приложение на живой экземпляр, как убедиться, что база сама с собой не пошла в рассинхрон. В этом ключе лучше, конечно, работают мастер-мастер решения… Ну, и поехало по нарастающей увеличения сложности

такая архитектура приложения, 6 бд — для сервисов каждый из которых самостоятельно может авторизоваться, 7я бд — сервис авторизации (мастер, модификация пользователея и некоторых других данных общих для для всех сервисов), изначально была сложная система взаимодействия между сервисами и сложно было гарантировать консистентность данных, потому решил сделать auth как мастер, основная цель — единая точка записи, и если вдруг отвалиться — остальные сервисы работают отлично

реплицируется бд A в бд B,C,D,.., причем каждый слейв имеет дополнительные таблицы, а пользователь приложения к реплицируемым таблицам в слейве имеет доступ только чтение, остальные таблицы — полный.

получили:
— возможность удобно масштабировать бд
— независимость сервисов от доступности auth
— упростили архитектуру приложения
— каждая бд в контейнере избавляет от проблем вдруг одна из бд отвалится, были случаи когда чтото не закрывает вовремя соединение или открывает слишком много — и вся бд стает в too many connection, и т.п., что нарушает идею сервисов.

а то что на 1й машине — такую дали :) да и нагрузка не более 200 rps, 1й машины хватает,

ну, в общем-то, это прекрасная иллюстрация того, к чему ведет "микросервисный" подход — к тому, что у каждого сервиса есть своя микроБД и своя копия данных. В результате необходимо обеспечивать консистентность всего это хозяйства. Вместо того, чтобы проксировать запросы по конвенциональным интерфейсам, Вы сделали жесткую связность между БД. Браво. Вот поверьте — во всех компаниях, где я работал, такую архитектуру разнесли бы в пух и прах.


— возможность удобно масштабировать бд

И получили геморрой обновления версии БД во всем кластере.

Если за каждый микросервис (и микроБД) отвечает ровно одна команда, то проблемы обновления как-бы наоборот решаются вот таким вот делением.
Собственно это главная причина развития парадигмы микросервисов, а не ИТшная мода.

Но не объединением всех микроБД в глобальный кластер на репликацию
Либо коллега использовал термин репликация в неверном значении…
В смысле — не репликация средствами самой БД, а в смысле логической перекачки данных (но это ещё вопрос насколько она нужна — это должен решать архитектор данных, например)

Конкретно в данном кейсе (тот который обсуждали в коментах чуть выше) — может быть не очень оправдано деление на мелкие БД в одной железке. Без контекста — сложно судить.

Но и обратное утверждения, что деление на «мелкие» БД — это всегда однозначно плохо, и так делать не надо, это утверждение тоже не всегда оправдано.

У всего есть своя цена. Решение принимать следует из конкретного контекста.
Есть ещё третья сторона, кстати.
Если нет требования держать данные on-premise, то можно положиться на облака, их нынче как грязи: Googe Cloud SQL и Cloud Bigtable, Amazon Aurora и DocumentDB, Azure SQL DB и CosmosDB, или даже Яндекс Managed *SQL и MongoDB

И это самый верный путь! Автоскейлинг облака и все ок )

1) дорого 2) у них бывают эпические факапы (у всех бывают эпические факапы, но за п.1 хочется решение «под ключ», чтобы не костылить сверху свои HA/FO/DRP)
(у всех бывают эпические факапы, но за п.1 хочется решение «под ключ», чтобы не костылить сверху свои HA/FO/DRP)

в случае полностью СВОЕЙ инфры Вам точно придется "костылить сверху свои HA/FO/DRP".
В случае облака — можно воспользоваться тамошними примитивами и сидеть в нескольких AZ.

5 лет назад вытаскивал постгрес из докера. Зачем запихнули и зачем вытаскивал хз, но зато на их ошибках понял, что если нужна бд с большими иопсами, то всегда дешевле взять 3 локальных виртуалки с проброшенными нвме, чем тратить ресурсы инженеров. А рулить всем этим уже можно через любую scm. У нас ансибл, со стейтами немного болеем, с багами чутка, но это явно перекрывается по плюсам низкой кривой входа нового сотрудника. Всё равно всегда к чартам и подам добавляют какой нибудь scm, ведь фулстек ничего корректно не покрывает. А вот любой стейтлес, сам бог велел в контейнеры запихнуть. Ну и от масштабов можно плясать выбирая композ — номад — к8с. Хорошо сделанные контейнеры в правке чаще всего не нуждаются.

СУБД поставщики уже озадачились и решили задачи с HA и масштабированием, причем более флигранно, с учетом особенностей своей СУБД.
Кластеризируя СУБД через k8s, вы наступите на те-же грабли, на которые наступали разработчики СУБД, только разруливать проблемы придется вам.
Я бы делал кластеризацию средствами СУБД, либо заплатил AWS за готовое решение.

Я тоже при прочих равных предпочту managed инстансы БД и прочих аналогичных сервисов.

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

Согласитесь, проектов, которым реально нужна база в контейнере, можно пересчитать по пальцам одной руки не самого лучшего фрезеровщика. В большинстве своем, даже само использование k8s или Docker Swarm бывает избыточно — довольно часто к этим инструментам прибегают из-за общей хайповости технологий и установок «всевышних» в лице гендиров загнать все в облака и контейнеры. Ну, потому что сейчас это модно и все так делают.

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

Согласен, с каждым словом.

… если с со stateless-приложениями все понятно, то как тогда организовать достойное обеспечение сетевой связности кластеризированной базы данных?

В мире СУБД PostgreSQL есть Patroni. Который (не только по моему мнению) уже стал стандартом для построения HA решений PostgreSQL.
Чтобы упростить и автоматизировать процесс развёртывания High-Availability кластеров PostgreSQL, я написал и опубликовал Ansible playbook
github.com/vitabaks/postgresql_cluster

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

Да, об этом стоит не забывать.

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