Как стать автором
Обновить

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

хранить данные в сетевом блочном устройстве Network Block Device

мне кажется это не может быть рекомендованным сценарием для серьезных БД вроде PG.
Аргументы:


  1. что будет, если сетевое хранилище отъедет?
  2. как известно, PG жаден до IOPS (все-таки WAL'ы надо на диск скидывать максимально быстро) — следовательно, приоритет за локальными дисками
  3. особой ценности в том, что под с базой переедет с ноды на ноду нету. Более того — кубернетес не гарантирует, что под на отказавшем из кластера узле будет убит. Чтобы была такая гарантия — нужно реализовать паттерн STONITH.

дополнительные сетевые задержки внутри Kubernetes задерживают работу базы данных

можно избежать при грамотном проектировании кластера


хранить данные в сетевом блочном устройстве

на пикче вижу Ceph. Это правда он или просто некое обобщение сетевых дисков?


Еще ни слова про Spilo и Stolon… :-(

мне кажется это не может быть рекомендованным сценарием для серьезных БД вроде PG.

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

Сетевой диск и консистентность — как будто оба слова противоречат друг другу ) Я уже один аргумент дал, почему это стремный конфиг.
Второй аргумент — никто не гарантирует как там fsync с коммитом в сетевое хранилище будет сделано. Точнее не так — есть куча мест, где процесс может сломаться. Был чудесный доклад от Капитулы, который рассказывает, как весь стек от гостевой операционной системы до raid-контроллера важен (там, правда, не просто сетевые диски, а сетевые диски в применении к гипервизорам, но проблемы общие).
Плюс мы прорабатывали сценарий ceph + kuber. Выводы: ceph должен быть снаружи (иначе жди проблем), сеть под ceph должна быть отдельная и максимально быстрая (иначе ломается межкластерное взаимодействие). В общем, это не конфиг тяп-ляп и в прод (и аргумент, что у вас все работает — он ничтожен, пока не проведены все возможные стресс тесты и инженеры пробовали ломать ее по-всякому)


Ещё раз. Если отказала нода с постгрес с любым хранилищем — там уже автоматом покоррапченные данные (да ещё и с отставанием от «головы»). Мы им доверять не можем. При этом у нас есть все ещё живые реплики. Почему мы должны пытаться оживить трупа, если можно восстановиться нормально, по-чистовому?

Сетевой диск и консистентность — как будто оба слова противоречат друг другу

Не в случае сефа, который в дефолте синхронно реплицирует и покрывает чексуммами. Консистентность это как раз про него.

Второй аргумент — никто не гарантирует как там fsync с коммитом в сетевое хранилище будет сделано.

Надо конечно копошиться в исходниках, но думаю все тоже самое. В RBD пойдет запись и ответ не будет получен, пока все OSD не ответят успехом.

ceph должен быть снаружи

С этим я не спорю.

Если отказала нода с постгрес с любым хранилищем — там уже автоматом покоррапченные данные (да ещё и с отставанием от «головы»)

Для этого есть синхронная репликация. Упала реплика — транзакция просто не закомитится.

А консистентность высокую я имел ввиду не то, что там банковские данные и судьба мира от этого зависит, а более простые. Чтобы конфликты разрешались, транзакции настоящие были, мертвые данные не воскрешали и прочие прелести всяких NoSQL, на которых у нас основная база.
Для этого есть синхронная репликация. Упала реплика — транзакция просто не закомитится.

не для этого, я про другое писал ) но не важно )
вообще — синхронная реплика — это дорого. Если это реально оправдано — ну, ок.
Ну, и жертвовать доступность в случае отказа sync реплики — тоже такое себе.

Доступностью можно не жертвовать. 2-я асинхронная реплика в данном сетапе при отказе синхронной становится синхронной. Это не является проблемой.

Поэтому именно на patroni предлагаю взглянуть внимательнее.

Ок. DCS, Load balancer — т.е. приходим к идентичной stolon архитектуре. Так почему в итоге патрони то выбрали?
Patroni отличается от Stolon тем, что в качестве компонентов DCS и Load balancer мы можем самостоятельно выбрать различные компоненты.
А много ли пользы от этого? Судя по всему, DCS у вас выступает сам кубер. Идентично столону, который тоже поддерживает разные варианты. Load balancer взяли сторонний отдельный компонент. Столон имеет свой. Теже яйца сбоку. Понятно, что между ними есть разница, но в статье это не раскрыто и выбор видится просто потому что так захотелось. Может быть мы вот столон используем, а у патрони какие-то реальные преимущества.

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

А как StatefulSet работает внутри? Докер же stateless контейнеры делает by design
Почему не используете peer-to-peer transactional replication?

3 нода, каждый на одном из 3 сетевых каналов дата-центра. При отказе любого нода, пока он восстанавливавается из дневного бэкапа, два других полноценно обслуживают клиентов.
Познакомимся с самыми популярными операторами, которые существуют для работы PostgreSQL внутри Kubernetes.

Мы недавно публиковали довольно детальное сравнение операторов для PostgreSQL (включая все перечисленные): часть 1 и часть 2 с итоговой таблицей.

Спасибо! Крутая статья

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

Зачем этот дополнительный слой абстракции

не жрет больше. Тебе для того же патрони все равно тащить etcd или консул..


усложняет дебаг?

это да


В чем профит от размещения баз в кубере?

возможность получить нечто вроде managed services for Postgres ;) на своей инфраструктуре.
Если не в кубаре — тебе все равно придется делать какую-то оркестрацию, решать вопрос хранения и бекапирования данных БД. На ансибле делать? На vrOps?

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