Комментарии 17
хранить данные в сетевом блочном устройстве Network Block Device
мне кажется это не может быть рекомендованным сценарием для серьезных БД вроде PG.
Аргументы:
- что будет, если сетевое хранилище отъедет?
- как известно, PG жаден до IOPS (все-таки WAL'ы надо на диск скидывать максимально быстро) — следовательно, приоритет за локальными дисками
- особой ценности в том, что под с базой переедет с ноды на ноду нету. Более того — кубернетес не гарантирует, что под на отказавшем из кластера узле будет убит. Чтобы была такая гарантия — нужно реализовать паттерн STONITH.
дополнительные сетевые задержки внутри Kubernetes задерживают работу базы данных
можно избежать при грамотном проектировании кластера
хранить данные в сетевом блочном устройстве
на пикче вижу Ceph. Это правда он или просто некое обобщение сетевых дисков?
Еще ни слова про Spilo и Stolon… :-(
мне кажется это не может быть рекомендованным сценарием для серьезных БД вроде PG.
Очевидно от нагрузки зависит. У нас вот PG нужен для примитивных нагрузок вроде базы пользователей и конфигураций. Нагрузки никакой, а вот консистентность нужна высокая. Работает сейчас на столоне в кубере, но все прибито к локальным дискам. Вот и тоже думаю, а чего бы их не убрать на сеф и снять с себя полностью головняк об отказах и как там столон восстановится после них. Чем меньше вот таких прибитых подов в кубере, тем лучше.
Сетевой диск и консистентность — как будто оба слова противоречат друг другу ) Я уже один аргумент дал, почему это стремный конфиг.
Второй аргумент — никто не гарантирует как там fsync с коммитом в сетевое хранилище будет сделано. Точнее не так — есть куча мест, где процесс может сломаться. Был чудесный доклад от Капитулы, который рассказывает, как весь стек от гостевой операционной системы до raid-контроллера важен (там, правда, не просто сетевые диски, а сетевые диски в применении к гипервизорам, но проблемы общие).
Плюс мы прорабатывали сценарий ceph + kuber. Выводы: ceph должен быть снаружи (иначе жди проблем), сеть под ceph должна быть отдельная и максимально быстрая (иначе ломается межкластерное взаимодействие). В общем, это не конфиг тяп-ляп и в прод (и аргумент, что у вас все работает — он ничтожен, пока не проведены все возможные стресс тесты и инженеры пробовали ломать ее по-всякому)
Ещё раз. Если отказала нода с постгрес с любым хранилищем — там уже автоматом покоррапченные данные (да ещё и с отставанием от «головы»). Мы им доверять не можем. При этом у нас есть все ещё живые реплики. Почему мы должны пытаться оживить трупа, если можно восстановиться нормально, по-чистовому?
Сетевой диск и консистентность — как будто оба слова противоречат друг другу
Не в случае сефа, который в дефолте синхронно реплицирует и покрывает чексуммами. Консистентность это как раз про него.
Второй аргумент — никто не гарантирует как там fsync с коммитом в сетевое хранилище будет сделано.
Надо конечно копошиться в исходниках, но думаю все тоже самое. В RBD пойдет запись и ответ не будет получен, пока все OSD не ответят успехом.
ceph должен быть снаружи
С этим я не спорю.
Если отказала нода с постгрес с любым хранилищем — там уже автоматом покоррапченные данные (да ещё и с отставанием от «головы»)
Для этого есть синхронная репликация. Упала реплика — транзакция просто не закомитится.
А консистентность высокую я имел ввиду не то, что там банковские данные и судьба мира от этого зависит, а более простые. Чтобы конфликты разрешались, транзакции настоящие были, мертвые данные не воскрешали и прочие прелести всяких NoSQL, на которых у нас основная база.
Поэтому именно на patroni предлагаю взглянуть внимательнее.
Ок. DCS, Load balancer — т.е. приходим к идентичной stolon архитектуре. Так почему в итоге патрони то выбрали?
3 нода, каждый на одном из 3 сетевых каналов дата-центра. При отказе любого нода, пока он восстанавливавается из дневного бэкапа, два других полноценно обслуживают клиентов.
Познакомимся с самыми популярными операторами, которые существуют для работы PostgreSQL внутри Kubernetes.
Мы недавно публиковали довольно детальное сравнение операторов для PostgreSQL (включая все перечисленные): часть 1 и часть 2 с итоговой таблицей.
Чем больше я читаю статей, тем меньше я понимаю цель таких вот действий. Мы делаем себе проблемы и героически их решаем? В чем профит от размещения баз в кубере? Зачем этот дополнительный слой абстракции, который жрет ресурсы и усложняет дебаг?
Зачем этот дополнительный слой абстракции
не жрет больше. Тебе для того же патрони все равно тащить etcd или консул..
усложняет дебаг?
это да
В чем профит от размещения баз в кубере?
возможность получить нечто вроде managed services for Postgres ;) на своей инфраструктуре.
Если не в кубаре — тебе все равно придется делать какую-то оркестрацию, решать вопрос хранения и бекапирования данных БД. На ансибле делать? На vrOps?
Кластер PostgreSQL внутри Kubernetes: что нужно знать для успешного внедрения