company_banner

Живут ли базы данных в Kubernetes?



    Как-то так исторически сложилось, что IT-индустрия по любому поводу разбивается на два условных лагеря: которые «за» и которые «против». Причем предмет споров может быть абсолютно произвольным. Какая ОС лучше: Win или Linux? На смартфоне Android или iOS? Хранить все в облаках или заливать на холодные RAID-хранилища и класть винты в сейф? Имеют ли PHP-шники право называться программистами? Эти споры носят, временами, исключительно экзистенциальный характер и не имеют под собой никакой прочей, кроме спортивного интереса, базы.

    Так уж получилось, что с появлением контейнеров и всей этой любимой нами кухни с докером и условным k8s начались и споры «за» и «против» использования новых возможностей в различных сферах бэкэнда. (Заранее оговоримся, что хотя чаще всего в данном рассуждении в качестве оркестратора будет указываться Kubernetes, принципиального значения выбор именно этого инструмента не имеет. Вместо него можно подставить любой другой, какой вам кажется наиболее удобным и привычным.)

    И, казалось бы, был бы это простой спор о двух сторонах одной медали. Такой же бессмысленный и беспощадный, как извечное противостояние Win vs Linux, в котором адекватные люди вполне себе существуют где-то посередине. Вот только в случае контейнеризации не все так просто. Обычно в таких спорах не бывает правой стороны, но в случае «применять» или «не применять» контейнеры для хранения БД все становится с ног на голову. Потому что в определённом смысле правы и сторонники и противники подобного подхода.

    Светлая Сторона


    Кратко описать аргументацию Светлой Стороны можно одной фразой: “Алло, 2к19 за окном!” Звучит как популизм, безусловно, но если вникать в ситуацию детально, там есть свои плюсы. Их-то сейчас и разберём.

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

    Правильно, данные. Сердце любого проекта — его данные: это может быть как типичная СУБД — MySQL, Postgre, MongoDB, так и хранилища, используемых для поиска (ElasticSearch), key-value хранилища для кеширования — например, redis, и т. д. Сейчас мы не будем говорить о кривых вариантах реализации бэкэнда, когда БД падает из-за плохо написанных запросов, а вместо этого поговорим об обеспечении отказоустойчивости этой самой БД под клиентской нагрузкой. Ведь когда мы контейнеризируем наше приложение и позволяем ему свободно масштабироваться для обработки любого количество входящих запросов, это закономерно увеличивает и нагрузку на базу данных.

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

    Намного логичнее кластеризировать не только само приложение, но и сервисы, отвечающие за хранение данных. При кластеризации и разворачивании независимо работающих и распределяющих между собой нагрузку веб-серверов в k8s мы уже решаем проблему синхронизации данных — тех же комментариев к постам, если приводить в пример какое-то СМИ или блогоплатформу. У нас в любом случае заводится внутрикластерное, пусть даже виртуальное, представление БД как ExternalService. Вопрос в том, что сама БД пока не кластеризирована — развернутые в кубике веб-серверы забирают информацию об изменениях из нашей статичной боевой базы, которая крутится отдельно.

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

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

    Кроме того, распределенная в кластерах модель БД позволяет уносить эту самую БД туда, где она необходима; если мы говорим о глобальном сервисе, то довольно нелогично крутить веб-кластер где-то в районе Сан-Франциско и при этом гонять пакеты при обращении к базе данных в Подмосковье и обратно.

    Также контейнеризация БД позволяет выстроить все элементы системы на одном уровне абстракции. Что, в свою очередь, делает возможным управление этой самой системой прямо из кода, разработчиками, без активного привлечения админов. Подумалось разработчикам, что нужна отдельная СУБД для нового подпроекта — легко! написали yaml-файл, загрузили в кластер и готово.

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

    Контейнеризация и, по сути, распределенная физическая топология БД вашего проекта помогает подобных валидольных моментов избежать. Не доверяете новичку? Окей! Поднимем ему собственный кластер для работы и отключим от остальных кластеров БД — синхронизация только по ручному пушу и синхронному повороту двух ключей (один тимлиду, второй админу). И все счастливы.

    А теперь настало время переобуться в противников контейнеризации БД.

    Тёмная Сторона


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

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

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

    Вообще, бытует мнение, что докер/кубик-мафия тупо подминает под себя клиентов, отдающих эти инфраструктурные вопросы на аутсорс. Ведь для того, чтобы работать с кластерами, нужны инженеры, которые способны на это и понимают вообще архитектуру внедренного решения. Мы как-то уже описывали наш кейс с изданием Republic — там мы обучили команду клиента работать в реалиях кубернетиса, и все остались довольны. И это было порядочно. Зачастую же «внедряльщики» k8s берут инфраструктуру клиента в заложники — ведь теперь только они понимают, как там все работает, на стороне клиента специалистов нет.

    А теперь представьте, что таким образом мы отдаем не только веб-серверную часть на откуп аутсорсу, но еще и обслуживание БД. Мы говорили, что БД — это сердце, а потеря сердца фатальна для любого живого организма. Короче, перспективы не самые лучшие. Так что вместо хайпового кубернетиса многим проектам стоило бы просто не жлобиться на нормальный тариф на AWS, который решит все проблемы с нагрузкой на их сайт/проект. Но AWS уже не модно, а понты дороже денег — к сожалению, и в IT-среде тоже.

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

    Если мы говорим о бесшовном инженерном решении, которым и представляется переход на k8s, то главная наша головная боль — это репликация данных в кластеризируемой БД. Какие-то СУБД изначально довольно лояльно относятся к распределению данных между отдельными своими экземплярами. Многие же другие не столь приветливы. И довольно часто основным аргументом в выборе СУБД для нашего проекта становится отнюдь не способность реплицироваться с минимальными ресурсными и инженерными издержками. Особенно если проект изначально не планировался как микросервисный, а просто эволюционировал в эту сторону.

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

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

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

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

    Вместо вывода


    Если вы ждете внятного вывода «виртуализировать или нет БД», то огорчим: его здесь не будет. Потому что при создании любого инфраструктурного решения надо руководствоваться не модой и прогрессом, а в первую очередь, здравым смыслом.

    Существуют проекты, на которые принципы и инструменты, идущие с кубернетисом, ложатся идеально, и в таких проектах наступает мир хотя бы в бэкэнд-области. А есть проекты, которым нужна не контейнеризация, а нормальная серверная инфраструктура, потому что они принципиально не могут перемасштабироваться под микросервисную кластерную модель, ибо упадут.
    ITSumma
    603,13
    Собираем безумных людей и вместе спасаем интернет
    Поделиться публикацией

    Комментарии 69

      +2
      А с каких это пор, BD нельзя «кластеризовать» без использования docker/k8s? Даже, банальная, мастер — слейв репликация, с каким-то видом фейловера, дает уже минимальный HA для базы данных, с минимальным временем простоя.
      Как по мне, проблемы баз данных в docker/k8s — лежат в другой плоскости.
        0
        Кто же говорит, что нельзя?:) Конечно можно. Тут обзор плюсов и минусов выживания именно в мире контейнеризированных систем, которые всё больше и больше начинают захватывать инфраструктурное пространство вокруг нас.
          +3
          Чувствуете подвох? Мы используем k8s или Swarm для того, чтобы распределить нагрузку и избежать падения основного веб-сервера, но мы не делаем этого для БД.


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

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

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

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

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


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

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


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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

                                          Условный тестовый стенд. Мощный сервер 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
                                    +1
                                    Во всём процессе интеграции БД в кубик нужно понимать 2 простых правила: 1. БД это всё-таки стейтфул приложение 2. Виртуальные/Распределённые файловые системы это не для БД. Всё.


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

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

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

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

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

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

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


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

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

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

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

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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

                                      А почему, собственно, нет? Если вам есть, что рассказать из своего опыта — пожалуйста, делитесь, многим наверняка будет интересно. Если нет, то можете просто почитать соседей по комментариям, я уверен, они много интересного смогут рассказать из своей практики.
                                +1

                                Статья подобна холивару есть ли жизнь на марсе.

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

                                          +1

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

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

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

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

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

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

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

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

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

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

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

                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                              Самое читаемое