Comments 27
WAL-G бы и Одиссея туда
По одисею не увидел, можете ткнуть?
Возможность кастомизации — это еще одна из причин, по которой нас и подкупил этот оператор
А есть сравнение производительности такого кластера в кубернетес с аналогичным на голой виртуалке?
Когда я игрался с zalando оператором у меня вышла разница чуть ли не в полтора раза по сравнению с дефолтным инстансом постгри. Вероятно я просто не смог нормально приготовить оператор...
Когда я игрался с zalando оператором у меня вышла разница чуть ли не в полтора раза по сравнению с дефолтным инстансом постгри
Подразумевается производительность?
Я думаю, что тут два момента
- нельзя сравнивать постгрес дефолтный и от цаландо. Надо сравнивать цаландо против кластерный постгрес с патрони
- зависит от хранилки и настроек сети. Уверен, что потюнить постгрес в кубе, чтобы он работал побыстрее. Я уж не говорю, что под постгрес в кубе надо ОТДЕЛЬНЫЕ НОДЫ кучера
и там и там по одной ноде
диск выдавал локальный.
ресурсы тоже одинаковые(в заландо реквестами выставлял)
по различиям:
zalano ставил внутри кластера openshift, соотвественно ОС — fcos, вместо докера — cri-o.
обычный инстанс был на centos7.
в итоге вышло
ВМ: 402 tps
zalando: 154 tps
есть мнение что проблема на самом деле как раз в лимитах куба, где то на хабре была статья, что лимит может вызывать тротлинг цпу даже когда до планки еще далеко. но в заландо я на тот момент не нашел как это отключить.
другой вариант — локальный диск отдавал контейнеру через local storage operator, и че он с ним там делает — большой вопрос. есть шанс, что была двойная запись.
Спасибо за уточнение. tps меняли из контейнера с постгресом или как-то по-другому (снаружи кластера)? Возможно, что дело в этом
при этом было подозрение на сеть, так что на самом деле для заландо делал два измерения:
через VIP (keepalive operator, прямо на сервис шифта вешал IP) — вышло 154 tps
через NodePort — вышло 145 tps
виртуальные диски располагались физически на одном ssd, полагаю, можно считать, что они были идентичны.
повторюсь, я не сильно шибко разбираюсь в постгре, вероятно я просто не умею его настраивать.
по keepalive operator у редхата: www.openshift.com/blog/self-hosted-load-balancer-for-openshift-an-operator-based-approach
Какого кучера?
"Уверен, что потюнить постгрес в кубе, чтобы он работал побыстрее. " Уверен в чём? Не понял.
Ещё такая штука обнаружилась
https://www.openshift.com/blog/how-to-deploy-and-manage-postgresql-on-openshift-using-the-robin-operator
Это не оператор, который ставит постгрес, но интерес сам подход со снапшотами на уровне хранения.
Percona тоже свой оператор выпустила, на базе crunchy data
https://www.percona.com/software/percona-kubernetes-operators
Интересует какой из операторов умеет zero-downtime failover (скорее всего это будет pgbouncer), когда при переключении мастера клиентские соединения не сбрасываются, а перенаправляются на новый мастер
Как мне казалось в операторах доступны разнообразные пулеры (Odyssey, pgpool, pgbouncer), которые и удерживают соединения клиентов.
На самом деле не всё радужно - у того же stackgres pgbouncer является частью пода с postgres.Ну и про приложения, которые требуют сессии забывать не надо.
По факту ZereDowntime для transaction-mode ready приложений даст Zalando, Stolon, Crunchydata. Причём у Stolon свой прокси, который еще и нагрузку балансировать умеет. Stackgres не даст такого из коробки. А KubeDB я уже не помню где pgbounser держит.
Я правильно понимаю что zero downtime это действительно zero downtime, то есть клиентские соединения не сбрасываются и не требуют повторного реконнекта? Мне коллега сообщил что отказались от кранчидейта именно по этой причине (это было правда несколько лет назад, может чтото поменялось)
Везде есть оговорки.
Приложение должно работать в транзакционном режиме, должна быть синхронная или реплика с минимальным отставанием. Если эти условия выполняются - то ошибки будут только по тем запросам, которые были к упавшей реплике или мастеру.
Остальные же коннекты, которые были в idle состоянии ничего не почувствуют.
Совершенно верно, но например тот-же pgbouncer сам это не будет делать, нужен или какой-то скрипт, который дергает pause/resume или чтото типа stolon-pgbouncer https://github.com/gocardless/stolon-pgbouncer
Обзор операторов PostgreSQL для Kubernetes. Часть 1: наш выбор и опыт