Инфраструктура PostgreSQL в Ozon Алексей Игнатов Дмитрий Васильев 

Около 9 тысяч PostgreSQL-инстансов Что такое инфраструктура PostgreSQL в Ozon 02.2022 

Что такое инфраструктура PostgreSQL в Ozon 02.2022 3 mega TPS 

Что такое инфраструктура PostgreSQL в Ozon 02.2022 4 Wal трафик GB/s 

Как оно было 5 • В начале было слово (заявки в Jira) • Ресурсы создавались вручную через GUI( Foreman) • Ручная раскатка конфигураций через Puppet • Рутина начала угнетать 

Что начали менять. часть 1 6 • Прикрутили плейбук на ansible для шедулинга размещения и создания базок • Работала в режиме cli • Данная схема абсолютно криповая и нерасширяемая • Рутина по заведению базок продолжала угнетать 

Что начали менять. часть 2 7 • Хватит это терпеть • Переписываем в виде сервиса на python • resman – RESource MANager • Пока остается режим cli который дергает api • resman + It-crowd = рутина заведения базок ушла 

К чему пришли в начале 2021 8 

Что сейчас 9 • Ресурc в виде БД Postgresql по кнопке • Базки заказываются через it-crowd • Наша группа начинает больше пилить и расширять инфраструктуру для Postgresql • Горизонтальное масштабирование инфраструктуры поддерживает вертикальный рост компании • Планы на большую автоматизацию работы инфраструктуры вокруг Postgresql 

Виртуализация: гипервизоры KVM 

KVM hypervisor 11 • Все системные вызовы транслируются практически 1:1. • Основной overhead – это эмуляция окружения (в нашем случае сеть). 

Деплой виртуальных машин 12 • Resman – scheduler ресурсов – Anti-Affinity: • dc • стойка в которой расположен гипервизор • shard-prefix (мягкое) Вес – утилизация гипервизора. • Hyper-man – управляет ресурсами гипервизора - позволяет создавать и управлять виртуальными машинами. 

Hyper-man API 13 Клиенты hyper-man: • Resman: создание/удаление. • Hyper-dog: манипуляция над всем кластером виртуальных машин (patroni cluster). • Hyper-man-cli: помогает на P0/1 накидывать ресурсы: • CPU • RAM • IOPS 

При создании виртуальной машины закладывается: • Online увеличение CPU – x2 • Online увеличение RAM – x2 • От 17k IOPS 

CPU: внутри гипервизора Медицинский факт: перевод с shared на exclusive снижает latency 15 Весь CPU pool поделен на 3 части: • Shared: здесь расположены все CPU не привилегированных виртуальных машин. • Exclusive: здесь расположены CPU эксклюзивных машин. • System: изолированный кусок пула CPU для функционирования hypervisor kernel, обслуживание сети в виртуальных машинах. 

CPU: внутри виртуальной машины 16 Распределение основных процессов внутри виртуальной машины: • К первым CPU bind’ятся pgbouncer • К последним CPU bind’ятся прерывания сетевой карты 

Memory: не делаем overselling 17 На staging работает KERNEL SAME-PAGE MERGING (KSM), позволяет экономить около 20% памяти: • Мы используем ”золотые образы” операционной системы. • Мы используем одинаковые версии софта, (кроме версий PostgreSQL). 

DISK 18 • Приходится использовать LVM для того чтобы обеспечить online-resize. • По IOPS есть математический overselling, фактического не наблюдаем. • Есть scheduler (hyper-dog), который делает автоматический ресайз дисков, но от него планируем отказаться, так как это приводит к неконтролируемому росту. 

Network v2: macvtap 19 • Ограничен только исходящий трафик (200MB/s), иногда упираемся в трафик реплик. • Пакетики обрабатываются как на стороне гипервизора, так и внутри виртуальной машине. • Рандомно трафик VM-1 был виден в VM-2, из-за чего обработка “очереди пакетов” тормозила весь гипер: https://access.redhat.com/solutions/2822941 

Network v3: sr-iov 20 • Ограничен только исходящий трафик (200MB/s), tc внутри виртуалки. • Трафик обрабатывается только внутри виртуальной машины • Нагрузочное тестирование: расходы cpu sys меньше в два раза, cpu irq в 10 раз. 

Балансировка 

Patroni + ETCD + Warden 22 

Application <--> PostgreSQL 23 

Hyper-dog: online resize 24 Hyper-dog (memory/cpu): • Проверяет целостность кластера. • Начинает с async, потом sync, потом leader. • Выводит из балансировки, если leader делает switchover, если синхронная реплика дожидается появления синхронной реплики. • Останавливает виртуальную машину, производит ресайз, запускает. • После запуска, если необходимо, делает тюнинг настройки PostgreSQL. 

Отказоустойчивость 

Patroni 26 Дополнительные костыли: • lag_guard (noloadbalance) • dc_guard (leader && sync в разных dc) • slot_guard (отстреливаем отставшие реплики) 

SCM: puppet -> ansible -> chiit !!! 

No content

chiit 29 Проблемы которые решаем: • Масштабирование: smart client -> server as storage. • Быстрый (по нагрузке на ноду) деплой и откат. • Прозрачность. 

Игнатов Алексей, Дмитрий Васильев Спасибо за внимание! [email protected], [email protected]