Comments 69
Как по мне, проблемы баз данных в docker/k8s — лежат в другой плоскости.
Чувствуете подвох? Мы используем k8s или Swarm для того, чтобы распределить нагрузку и избежать падения основного веб-сервера, но мы не делаем этого для БД.
Мой посыл был как раз к этой строчке. Кто им мешает кластеризовать ДБ нативными методами для конкретно взятых ДБ, при чем тут вообще докер с кубером. Как будто, до появления контейнеров ни приложения, ни базы данных никак не кластеризовались и не маштабировались.
Потому, я повторюсь, на мой скромный взгляд, проблема баз данных в k8s лежат в другой плоскости.
Кто им мешает кластеризовать ДБ нативными методами для конкретно взятых ДБ
Никто не мешает. Вполне возможно, они именно так уже и делают. Но раз уж решили завести централизованное управление всем своим проектом, в самой своей основе предполагающее механизмы распределения нагрузки, фейловеров и пр, то логично что было бы удобнее через одну точно и управлять всем хозяйством разом? Чтобы можно было строить сценарии с зависимостями от нагрузок подсистем друг на друга, в рамках одной системы вести мониторинг, обмениваться данными и пр пр.
Потому, я повторюсь, на мой скромный взгляд, проблема баз данных в k8s лежат в другой плоскости.
Да, и это другие плоскости рассмотрены ниже:)
Никто не мешает. Вполне возможно, они именно так уже и делают. Но раз уж решили завести централизованное управление всем своим проектом, в самой своей основе предполагающее механизмы распределения нагрузки, фейловеров и пр, то логично что было бы удобнее через одну точно и управлять всем хозяйством разом? Чтобы можно было строить сценарии с зависимостями от нагрузок подсистем друг на друга, в рамках одной системы вести мониторинг, обмениваться данными и пр пр.
Когда у вас в руках молоток, все вокруг видится гвоздями.
Да, и это другие плоскости рассмотрены ниже:)
Как раз нет, точнее — очень вскольз затронуто.
Чувствуете подвох? Мы используем k8s или Swarm для того, чтобы распределить нагрузку и избежать падения основного веб-сервера, но мы не делаем этого для БД.
Мой посыл был как раз к этой строчке. Кто им мешает кластеризовать ДБ нативными методами для конкретно взятых ДБ, при чем тут вообще докер с кубером.
Там акцент другой:
«Всем хороша кластеризация в Kubernetes, кроме случая использования её с СУБД.»
Речь о кластеризации именно что с Kubernetes, а не любой кластеризации вообще.
Единообразия ради хотелось бы в Kubernetes, но не желательно в общем случае.
Только с мелкими базами данных и возможно. С чем серьезным — ни-ни.
А кластеризация другими средствами — это вообще о другом. Только слово «кластеризация» то же само для обозначения используется — но не более.
Архитектурно-то построено иначе.
Да мускул на гигабайт дб под вордпрес будет прекрасно себе жить в k8s.
То что решается при «классическом» методе инталции кассандры через пару команд nodetool и дождаться окончания, перед началом других действий, в том же k8s тянет за собой написание обвязки дополнительной, в которой могут и будут баги и т.п.
Ну и про размер, ребаланс на 1 гигабайте данных и пол петабайта — это разное время, которое, вы, заранее знать не можете, потому сразу вопрос, какой таймаут для грейс шутдаун пода вы будите выставлять? Так что, в случаи той же касандры, просто вывести члена кассанда кластера чуть более сложнее чем, kubectl delete pod.
И тут еще не затрагивался вопрос гео-распределенного кластера.
Как раз, как работает шедулер кубера мы разбирали и очень основательно.
Так что, профит от унифицированой среды, во многих кейсах, стремиться к нулю.
Какой вы, кстати, выставляете «таймаут для грейсшатдауна» когда у вас сервер вырубается?
Я не просто так выше писал про штатную ситуацию, если надо вывести члена кластера.
Отработка фейловера — это отдельная тема.
тут всё решаемо средствами доступными из коробки.опасное заблуждение, на которое, мы так же нарвались. Все же эксплуатация больших, распределенных дб — очень сложный процесс сам по себе. С кучей подводных камней и неявных моментов. А унификация, которую все так хотят, только, привнесла дополнительный слой проблем, которые тоже пришлось решать. И профита, для бизнеса, в первую очередь, не принесло никакого.
Потому что чтобы в куб засунуть БД, надо, чтобы она изначально была спроектирована под этот оркестратор. Популярных БД таковых нет. А в остальном ситуация с засовыванием легаси баз в куб выглядит как попытка катить квадратное и носить круглое. Но! Если рассмотреть куб немного с другой плоскости — а именно как просто плоский пул ресурсов распиленных на ноды и вы гарантируете, что эти годы достаточно отказоустойчивы, то можно с ворохом обвязок запускать БД на выделенных нодах и они будут себя прекрасно чувствовать. Другой вопрос, что это куб ради куба получается.
Насчет того насколько сложно допилить условный постгрес до готового к Кубу состояния — посмотрите, напр., на проект stolon. Был один сервер бд (как приложение) — стало 100500 компонентов. И никто не гарантирует, что в них нет багов и не поясняет границы работоспособности этого карточного домика
Ну, и приходим к тому, что нужны
а) локальные диски (они быстрые или по крайней мере могут быть такими)
б) изначально распределенные БД на уровне дизайна (kuber-native) — популярных ПОКА НЕТ. И на самом деле еще вопрос нужны ли они.
Я согласен, что если упрощать, то да, кубернетес — всего лишь менеджер вычислительных ресурсов (как YARN, например, как Mesos или любой другой). И в этом контексте действительно без разницы — запускать базу в контейнере (т.е. по факту ц-группе) или нативно. С другой стороны, любая абстракция приносит с собой дополнительную сложность. О чем выше я и пишу. Те же базы ОЧЕНЬ не любят, когда кроме них на хосте что-то есть. И это от проблемы "шумных" соседей (когда iops, например, начинают пропадать из-за того, что кто-то рядом запустил ресурсоемкое приложение), и кончая тем, что тем же монгам и кликхаусам нужно вручную задавать кол-во аллоцированных ресурсов (до сих пор не во всем софте пофиксили правильное определение доступных ресурсов — процы, память и пр.; про опыт с Монгой могу рассказать, если интересно). Но последнее — это не только кубернетес-специфично, это вообще, если нужно шарить хост между несколькими задачами.
Вторая большая проблематика заключается в том, что кубернетес — это про запуск чего-либо на дешевом дерьмовенком железе, либо в облаке, желательно на спотовых инстансах, чтоб подешевле было. Т.е. любая вычислительная нагрузка будет убита в любой момент времени. База же — это сервис, который должен работать постоянно. МОЖНО собрать отказоустойчивый сервис БД в таких условиях, но опять же это требует больше действия, чем просто развернуть на каком-либо дедике какой-либо мускуль.
Поэтому движение в светлое будущее с правильным софтом должно быть с обеих сторон.
Ну а на счёт дерьмового железа это не совсем и не всегда
У каждого свои критерии. Но давайте возьмем какой-нибудь Хадуп. Цель его разработки была именно обеспечить возможность массовой параллельной обработки данных на low-end железе, т.к. high-end избыточно дорог и вертикально долго не отмасштабируешься. Ну, и понятно, что low-end железо имеет более облегченные параметры надежности. Короче — диски будут вылетать постоянно. Возможно и что-то еще. Поэтому система сразу проектировалась с прицелом на то, что ноды могут умирать. А как только это было сделано — условно стало возможно собирать хоть из б/у вторсырья (опять же есть другие критерии — например, iops, которые ограничивают предел, целостность данных и т.п.).
У нас так получилось, что в ДЦ стоят лошадиные машины под основной проект которые 80% времени используются на 20% мощности
Т.е. опять кейс — более полная утилизация баре-метала? Может стоило на ВМ мигрировать?
Но давайте возьмем какой-нибудь Хадуп.Мы сейчас вообще не в те дебри полезли. Давайте я вам сейчас еще одну байку расскажу про железо и не совсем железо. Случилось так, что в нашей конторе маркетологи не расчитали своих сил и рекламная компания прошла уж очень успешно, на столько успешно, что вместо планировшихся 20к пришло 150к пользователей. Система держалась как могла, но графики стали упираться в потолок. Тупо не хватало ресурсов. Большие боссы сказали: всё равно сколько будет стоить, проект должен быть онлайн, покупайте любое железо. Мы по дёрнули провайдера на предмет быстро доставить в стойки серверов, сказали — зайдите через недельку. А нагрузка растёт. Тогда пошли в амазоновское облако наподнимали ec2, добавили их в кубик и скинули туда все второстепенные сервисы. Проект скрипел, иногда подтупливал, но остался онлайн. Заняло это всё меньше часа и то из-за того, что ждали пока бд зальются. От опаратора потребовалось только раставить метки на новые инстансы, ну и дёрнуть нужные поды. Как только пик спал, инстансы убрали и всё вернулось в дц. Смогли бы мы так же расширится используюя стандартные методы, скорее всего да, но не такой малой кровью и пожалуй процент ошибок был бы больше. Всё-таки человеческий фактор, а слишком много того, что кубик делает автоматом пришлось бы делать руками.
Может стоило на ВМ мигрировать?Надеюсь, Вы шутите.
Мы по дёрнули провайдера на предмет быстро доставить в стойки серверов, сказали — зайдите через недельку.
Типичная история. Поэтому будущее не за какой-то определенной технологией (ТОЛЬКО баре-метал, ТОЛЬКО облако и пр.), а за их синергией и правильным применением наиболее подходящей комбинации в текущей ситуации.
Надеюсь, Вы шутите.
Ценность куба, в случае, если можно делать проект на автоскейлинг группах в том же амазоне? И то — эластично, и то — эластично.
Во первых, конечно, интересно. Хоть и не видел еще задач которые Монго решала.
Условный тестовый стенд. Мощный сервер 32 ядра, 256 ГиБ ОЗУ. Нужно развернуть монга с 1ТБ данными. КХ для аналитики. И кучу мелких сервисов. На всякий случай поясню, что при прочих равных лучше было бы разделить сервисы по отдельным серверам. Дефолтный конфиг — нет памяти. Выясняем, что монга кушает чуть больше, чем дофига. По факту — "горячих" данных столько нет. Решаем, что самые умные и выставляет лимиты монге через systemd unit. Скажем, 20ГиБ. Монга начинает регулярно рестартовать. По ходу в приложеньках исправляем ситуацию, что теряется коннект (а то! в продакшене может случиться что угодно!) и чтоб они рестартовали запросы в случае ошибки. Окей. Читаем внимательно доку на Монгу. Оказывается! Что если памяти много, то она аллоцирует 50% от памяти хоста под свои нужды. Решилось банально указанием в командной строке сколько же памяти есть у монги.
Далее. Проблемы с це-группами вообще типичны.
- nginx пофиг на ограничение по cpu: https://github.com/kubernetes/ingress-nginx/issues/2948
- в 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 спроектированной.
мне тоже внезапно (о чем я выше и удивляюсь). Видимо, не надо!?
Не прекрасно и не с минимальными.
Миграция бд по подам то ещё извращение.
А уж про производительность этого решения лучше как о покойниках...
Что убивает практически весь смысл в кубике. Ибо для таких подов нет скейлинга, миграций и т.п.
Спрашивается — какой в этом смысл?
Кубик ради кубика (унификация среды). Ценой резко возросшей стоимости владения этим всем.
Первое это, конечно, перенести бд в неймспейс основного приложения, чтобы не гонять пакеты по сетям
Нет. То что БД в том же неймспейсе, что и основной приклад совершенно не означает, что БД и приклад попадут на один хост. А даже если они на одном хосте — пакеты будут все равно через вирт. сеть гоняться. А теперь вопрос — зачем весь этот оверхед. В старой архитектуре у нас просто был физический сервер с БД и физический сервер с прикладом. Никаких дополнительных накладных расходов на передачу данных.
Второе, ну кто вам сказал, что такие вещи не скалируются, скалируются за милую душу, только не так легко как стейтлессы, чуть больше магии. Пример который прям под рукой, с мускулом: Нужен мне еще один слейв я его репликой поднимаю, инит контейнер подтягивает бекап меняет позиции в бинлоге, находит мастер и отдаёт управление основному контейнеру который уже на всё готовое запускает мускул.
Если условная база — 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 для бд (обычно космические надсткойки с хитрыми скриптами, чекерами и т.п.), потому зачем яму копать, если с десятком-сотней контейнеров можно справиться одним баш-скриптом… вот и все окрестрация.
Я так предполагаю, что для кубернетеса поды — не долгоживущие сущности, которые могут быть отстрелены в любой момент времени. Соответственно, чтобы база как сервис выжила — она должна быть запущена в нескольких репликах. Но далее возникают дополнительные вопросы: как переключить приложение на живой экземпляр, как убедиться, что база сама с собой не пошла в рассинхрон. В этом ключе лучше, конечно, работают мастер-мастер решения… Ну, и поехало по нарастающей увеличения сложности
реплицируется бд 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
5 лет назад вытаскивал постгрес из докера. Зачем запихнули и зачем вытаскивал хз, но зато на их ошибках понял, что если нужна бд с большими иопсами, то всегда дешевле взять 3 локальных виртуалки с проброшенными нвме, чем тратить ресурсы инженеров. А рулить всем этим уже можно через любую scm. У нас ансибл, со стейтами немного болеем, с багами чутка, но это явно перекрывается по плюсам низкой кривой входа нового сотрудника. Всё равно всегда к чартам и подам добавляют какой нибудь scm, ведь фулстек ничего корректно не покрывает. А вот любой стейтлес, сам бог велел в контейнеры запихнуть. Ну и от масштабов можно плясать выбирая композ — номад — к8с. Хорошо сделанные контейнеры в правке чаще всего не нуждаются.
Кластеризируя СУБД через k8s, вы наступите на те-же грабли, на которые наступали разработчики СУБД, только разруливать проблемы придется вам.
Я бы делал кластеризацию средствами СУБД, либо заплатил AWS за готовое решение.
Особенно склонных к хайпу менеджеров.
Согласитесь, проектов, которым реально нужна база в контейнере, можно пересчитать по пальцам одной руки не самого лучшего фрезеровщика. В большинстве своем, даже само использование k8s или Docker Swarm бывает избыточно — довольно часто к этим инструментам прибегают из-за общей хайповости технологий и установок «всевышних» в лице гендиров загнать все в облака и контейнеры. Ну, потому что сейчас это модно и все так делают.
…
В свете всех этих «приключений» намного выгоднее и проще держать БД в одном месте, и даже если вам потребовалась контейнеризация приложения — пусть оно крутится само по себе и через распределительный шлюз получает одновременную связь с БД, которая будет читаться и писаться лишь один раз и в одном месте. Такой подход снижает вероятность ошибок и рассинхронизаций до минимальных значений.
Согласен, с каждым словом.
… если с со stateless-приложениями все понятно, то как тогда организовать достойное обеспечение сетевой связности кластеризированной базы данных?
В мире СУБД PostgreSQL есть Patroni. Который (не только по моему мнению) уже стал стандартом для построения HA решений PostgreSQL.
Чтобы упростить и автоматизировать процесс развёртывания High-Availability кластеров PostgreSQL, я написал и опубликовал Ansible playbook
github.com/vitabaks/postgresql_cluster
Ведь для того, чтобы работать с кластерами, нужны инженеры, которые способны на это и понимают вообще архитектуру внедренного решения.
Да, об этом стоит не забывать.
Живут ли базы данных в Kubernetes?